Marlin4Due

Sorry. I will make an update later. I've changed a lot in the last days.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

No apology needed! I got through it, and it got me into the code as well, which is good. I was just not certain of what has and has not been tried, so sending in my observations in case it saves some time or grief. To that end, I had one more thing I needed to correct, which was commented to lead meto believe that is was a change from the Due port . . . . the function 'tone', as referenced by, iirc, 'lcd_buzz' in the graphics controller code is 3 parameters, but the core function has only two (dropped the 'duration' parameter) causing a compile fail. Simply adding a dummy var back to 'tone' resolves that one . . . not a good fix, but gets it to bukld for testing.

Hopefully, I'll have a HW test bed before too long (Due + RAMPS-FD) and can be of some value as a tester . . .

- Tim

The tone() is fixed allready.
Also i've made an update for delta-bots. Hopefully this works.

But there are some bugs for delta at the moment which will be solved soon.
Some bugs which are in the Marlin8bit are also in my repository. But there are a lot of programmers which make a fantastic job to solve such issues.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Thanks - I'll update my git clone and take a look!

- Tim

OK, finally got a chance to do some testing on this . . . pulled changes as of yesterday, IIRC, so this should be on most-current as per GitHub . . .

Using an authentic Due, and the Geetech variant (bastardization?) of RAMPS-FD, V1 . . .

First, I can't duplicate the problem with the heaters going on on code loads or reboot . . . and this is definitely a V1 RAMPS-FD . . . so I have to wonder if changes have happened to the Due.
In any case, the V1 options in Marlin4due handle the inverted heaters just fine.

What is *NOT* working is layer fan control . . . that is still reversed, and since it is using PWM, simply inverting "WRITE_FAN" in Conditionals.h (as was the case for WRITE_HEATER) does not work, and I have not had a lot of luck finding where to invert this, but working on it. The practical upshot is that the fan *IS* on when the board boots, and M106/M107 are backwards . . . not usable.

Any thoughts on this? I'm digging, but figuring out what/where is actually writing the fan pin is hiding in layers of obfuscation (or at least I see it that way . . . ).

The pins_RAMPS_FD.h is close, but not quite. For some reason, bob left the MAX endstop pin definitions out of his template, and the values for X_MAX and Y_MAX in the file are not correct.

This is verified good :

#define X_MAX_PIN 30
#define Y_MAX_PIN 38
#define Z_MAX_PIN 34

I also defined FAN_PIN, but that is correct as HEATER_1_PIN as written . . . just the pins_RAMPS_FD.h file does not have a layer fan configured!

I have not gotten a motor on it yet, but stepper setup looks good . . .

What I *cannot* get working is my RepRap Graphic Controller. The encoder appears to work, since I get audio feedback from pressing the selector, and I can see the SD card fine, pretty much verifying cables to be correct. The LCD does not init at all (I have back light . . .), and I know that it is good, since I have a Mega on my printer running 1.0.3-dev as well, and the same config drives it fine there. I have still to check output pin config to ensure that the LCD adapter and pins_RAMPS_FD.h agree on where signals need to be, but barring that, either there is a glitch here, or the buffer on my LCD adapter card is dead . . . not much else left that can't be confirmed elsewhere.

Any suggestions on the LCD would be welcome, and I will update as I move along regarding the config. I am very close to putting it into the printer, but really would like a functional layer fan first . . . the display is a desire, the fan a must!

UPDATE: Using SOFT_PWM on the fan causes it to use the WRITE_FAN conditional, for which I added the INVERTED_HEATERS conditional, which now works. This still needs correction at the base level, but should now be usable.

LCD pins look OK, but still no joy . . .

- Tim

Edited 5 time(s). Last edit at 05/30/2015 11:34PM by tadawson.

Actually I don't have a graphic LCD and can't help you with that.
I should get some for testing in the next week maybe. It's for a RADDS but this should be near the same. If I have any luck with that I let you know it.

The fan-issue should be not a big deal. I will dive into it tomorrow.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

when i use marlin4due these 3 red lights turn on they are leds on D8,D12 and D8. i have drv8825 driver, 115200 baud rate, changed config.h to match my port. i am trying to use my motor using repetier with no luck. when i use the repetier firmware I only get led D2 to turn on, but again nothing happens. I'm pretty frustrated right now with my ramps fd. i already ordered an eeprom for my due, but i want to solve one problem at a time before inadd more variables. i am using windows 7 home edition.

+Maxim Melcher in Google+ has successfully added an LCD 12864. He upgraded the 47uF 16V capacitor to 100uF 16V on his Due.

Quote
3DLTech
when i use marlin4due these 3 red lights turn on they are leds on D8,D12 and D8. i have drv8825 driver, 115200 baud rate, changed config.h to match my port. i am trying to use my motor using repetier with no luck. when i use the repetier firmware I only get led D2 to turn on, but again nothing happens. I'm pretty frustrated right now with my ramps fd. i already ordered an eeprom for my due, but i want to solve one problem at a time before inadd more variables. i am using windows 7 home edition.

What board definition did you use? You need to define RAMPS_FD_V1, IIRC, or the heaters run inverted as you noticed. (Unless you build your own -V2 board, then define with _V2 . . . ).

Having FET4 and FET5 active (the two to the far edge of the card) really isn't an issue, since a) Marlin does not control that many devices as delivered and 2) There are no FETs on those channels, so nothing to harm. D8 is the bed heater, and should *not* be active by default if the card definition is correct.

And I can say for a fact, having been testing mine on the bench yesterday, that the current Marlin4due build defined with the correct board (the repository defines RADDS as pulled) works on the heaters.

If you can, please post your Configuration.h file, so we can see what is going on.

I just am dying working on my LCD . . . all else seems good from here.

- Tim

Edited 1 time(s). Last edit at 06/02/2015 02:35AM by tadawson.

Quote
3DLTech
+Maxim Melcher in Google+ has successfully added an LCD 12864. He upgraded the 47uF 16V capacitor to 100uF 16V on his Due.

Thanks. Do you know if that was required to get it to work, or just something he did to beef up the Due 5v supply. (I plan to offboard my 5v from the Due anyhow . . . ).

Also, might you know what LCD define he used?

Oh, and any time to look at the fan issue?

Looks like my next step on the LCD may be to run flying leads to it, and bypass the daughter card and it's level shifting chip. Everything works on the panel that does *NOT* go through that chip - full SD card, and the encoder responds, so I may well just be looking at a bad chip . . .

Thanks,

- Tim

Edited 1 time(s). Last edit at 06/02/2015 02:36AM by tadawson.

Tim please see attached my configuration.h file. Thanks for thinking I could build my own V2.

Edited 1 time(s). Last edit at 06/02/2015 10:10PM by 3DLTech.

@ 3DLTech

Thanks!

Edited 1 time(s). Last edit at 06/03/2015 09:48AM by AndrewBCN.

Looking at your config, I'd start with setting the thermistors to a valid value - hard to tell what you will get using '0', when the notes clearly state 'Not Used' for that value. Then, depending on what temp reads (thermistor present or not), heaters may lock out if temp reads too high or low, but you can temporarily tweak MAX and MIN temps to test.

Did you edit any other files?

- Tim

Tim I can't run any of my motors. I modified the pin_Ramps_FD.h file too. What is IIRC?

Edited 1 time(s). Last edit at 06/02/2015 11:35PM by 3DLTech.

I haven't gotten mine into my printer yet (working on all the other subtle things first, since I don't want to install, hit a bug, and remove) so I have not confirmed motors working yet, but considering that it is the first thing I think the devs would test, hadn't spent much time on it. What I do notice is that I have not been able to find a doc showing the orientation of the Pololu modules installing on the RAMPS-FD card, and just took my DVM to it to make that determination, and it appears that the two rows sit opposite to each other . . . Any chance you have your drivers in reversed?

Oh, and pins file looks good from here . . .

And IIRC, IIRC, means "If I Recall Correctly" . . .

- Tim

Quote
3DLTech
Tim I can't run any of my motors. I modified the pin_Ramps_FD.h file too. What is IIRC?

Which stepper driver do you use?

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I am using DRV8825 1/32 microstepping. the RampsFD wiki has a picture that shows P107 as a heater power input. however Bobs Power.sch schematics indicates P107 is used to power the motors. Can someone include a picture of a setup I could use to test the motors?

Tim you are correct the rows for the drivers are inverted. The boards have a chevron that indicates ground. I aligned the GND on the driver to the chevrons. The picture I attached should be the right orientation for the DRV8825......unless the chevrons mean VCC then there is my problem.

BTW i had to solder all the driver pins om the top of the board. They had zero solder on them. Very difficult to do after the driver rows are installed.

Ok, the DRV are relativ slow. It's not a cicuit-issue.
I will make a PR to solve it for 'slow' drivers.

A fast solution for the slow stepper driver is simple overwrite the

#define WRITE(pin, v) _FASTWRITE(pin, v)

with

#define WRITE(pin, v) digitalFastWrite(pin, v)

It's in the fastio.h

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

My fastio.h does not have the _FASTWRITE(pin,v) command.

Quote
3DLTech
My fastio.h does not have the _FASTWRITE(pin,v) command.

@3DLTech

-> you have to update your copy of the Marlin4Due repository, the present fastio.h file is radically changed from earlier ones.

Right Andrew, but the latest fastio.h could be too fast. I should stick my drv on my corexy to test it. Bought them 1 month ago but didn't test it.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

@ Wurstnase

Hi,
I have just checked the datasheets for both the A4988 and the DRV8825, they require respectively a 1uS minimum low and 1uS minimum high pulse width (A4988 datasheet), and 1.9uS minimum low and 1.9uS minimum high pulse width (DRV8825 datasheet).

On a 16MHz AVR MCU, these minimum pulse widths are easy to get/respect, but on an 84MHz ARM Cortex M3 MCU, you have to pay more attention to how you code this.

So I agree with you, the latest fastio.h on Marlin4Due will possibly be too fast, an analysis of the compiled assembler code would confirm this.

There is a DelayMicroseconds() function in the Arduino libraries, I am not sure what the shortest delay it is able to generate on a Due is, this would have to be investigated further.

So apparently this problem is not as easy to solve as it looks like at first glance.

Quote
AndrewBCN
@ Wurstnase

Hi,
I have just checked the datasheets for both the A4988 and the DRV8825, they require respectively a 1uS minimum low and 1uS minimum high pulse width (A4988 datasheet), and 1.9uS minimum low and 1.9uS minimum high pulse width (DRV8825 datasheet).

On a 16MHz AVR MCU, these minimum pulse widths are easy to get/respect, but on an 84MHz ARM Cortex M3 MCU, you have to pay more attention to how you code this.

So I agree with you, the latest fastio.h on Marlin4Due will possibly be too fast, an analysis of the compiled assembler code would confirm this.

There is a DelayMicroseconds() function in the Arduino libraries, I am not sure what the shortest delay it is able to generate on a Due is, this would have to be investigated further.

So apparently this problem is not as easy to solve as it looks like at first glance.

What I do in RepRapFirmware for Duet electronics (which uses the same ATSAM3X8E processor) is to set the pin high when it is determined that a step is needed, then do other work (i.e. calculate the time when the next step is due) before setting the pin low again. I also have a timer running at MCLK/32 so that I can time things to a resolution of 0.38us.

Edited 2 time(s). Last edit at 06/03/2015 02:35PM by dc42.

---

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].

@dc42 Reprapfirmware has a lot of nop on this point? At least the last time I checked it, this weekend.

Edit: just a simple delay in reprapfirmware
[github.com]
[github.com]

platform->StepHigh(Z_AXIS);
ShortDelay();
platform->StepLow(X_AXIS);

Marlin4Due made some stuff when it handles the direction, so Marlin don't need any delay.

@Andrew I have already a really good solution. Hopefully this will work.

Edited 2 time(s). Last edit at 06/03/2015 03:29PM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase
@dc42 Reprapfirmware has a lot of nop on this point? At least the last time I checked it, this weekend.

My fork doesn't. Perhaps the official RepRapPro version does, I haven't checked. My fork uses totally different Move code.

---

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].

Quote
dc42

Quote
Wurstnase
@dc42 Reprapfirmware has a lot of nop on this point? At least the last time I checked it, this weekend.

My fork doesn't. Perhaps the official RepRapPro version does, I haven't checked. My fork uses totally different Move code.

That's your dev-fork!?

Edited 1 time(s). Last edit at 06/03/2015 03:44PM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Quote
Wurstnase

Quote
dc42
My fork doesn't. Perhaps the official RepRapPro version does, I haven't checked. My fork uses totally different Move code.

That's your dev-fork!?

Yes. The main branch of my repo was originally set up to track the RepRapPro official release, although it's somewhat out of date now. I use different branches for highly experimental work.

---

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].

Quote
dc42

Quote
Wurstnase

Quote
dc42
My fork doesn't. Perhaps the official RepRapPro version does, I haven't checked. My fork uses totally different Move code.

That's your dev-fork!?

Yes. The main branch of my repo was originally set up to track the RepRapPro official release, although it's somewhat out of date now. I use different branches for highly experimental work.

Sorry, but I don't understand you.
First it's not yours. Then it's yours but there is some highly experimental somewhere nobody can see? Your dev-branch is only 13 days old.

Edited 1 time(s). Last edit at 06/03/2015 05:09PM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.