Marlin4Due

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.

Not anymore too fast There is a new config option in the configuration.h. Just below the steps/mm-settings.
For everyone who are <120kHz can deactivate the ENABLE_HIGH_SPEED_STEPPER, you don't need it. This is the standard.

Pretty easy to calculate your maximum kHz. It's your steps/mm * max velocity.

If you use GT2 with 20 tooth, a standard cartesian printer with DRV8825 with 1/32 you have 160steps/mm. If your max speed is below 750mm/s, you don't need ENABLE_HIGH_SPEED_STEPPER.
With CoreXY it 750mm/s / squareroot(2) = 530mm/s.

Or more simple, everyone who has no move faster than 500mm/s and has DRV8825 or A4988 driver don't need to activate it.

And the best of it, no delays used for this

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

OK, well done!

Any chance to look at the inverted fan issue yet?

Thanks,

- Tim

I just loaded most recent Marlin4Due files. It doesn't stop compiling, its in some sort of endless do loop.

Quote
tadawson
Any chance to look at the inverted fan issue yet?

Sorry forgot you. Maybe tomorrow.

Quote
3DLTech
I just loaded most recent Marlin4Due files. It doesn't stop compiling, its in some sort of endless do loop.

Can you upload your config? Which Arduino-Version do you running?
You could also enable the debug-part in the arduino ide to 'normal'. Then you will see where it starts hanging.

Edited 1 time(s). Last edit at 06/04/2015 04:06AM by Wurstnase.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I am using Arduino 1.6.4 Please find attached my configuration.h file. The only change I made was I changed from RADDS to BOARD_RAMPS_FD_V1. Did you see my comment on the heater/motor(P107) labels and schematics not matching? Is my comment relevant?
BTW
Thanks for all the support to you and Andrew.
Jaime

Ah, I think I found my mistake. Did not test it actually but there is a missing #define in the config for the new stepping part.
Here is an update.

Edit: There is something wrong... Can't find the problem now. I will look again this afternoon.

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

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ok, I've tested my 'testing branch': [github.com]

Compiling on Linux I don't have any issue with 1.6.4.
Compiling on Windows, hang with 1.6.4. No issue with 1.6.3.

Can't compile the master branch on any Arduino Versions on Windows. Can't test Linux at the moment.

So please use my testing branch with Arduino 1.6.3. You can use the configs of the master.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

Ok, I'm at home now. I can't reproduce the issue on my computer. I run Linux here and don't have a Windows machine. I don't have any issue with 1.6.4 with any branch.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

i am not home this weekend I will test it tomorrow night.

Did anyone find out why the Firmware does not compile in Windows?
Regards,
Jaime

Actually I use 1.5.8 because it's compatible with Eclipse. I think that 1.6.4 has some bugs.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

I also believe I found out why I could not make the motors work and I found this out when I was attempting the test with my standard RAMPS board. I did not have my thermistors installed so Repetier would not recognize any of the motors. Once I hooked up the thermistors I was able to move the motors with my RAMPS board. I quickly switched out the boards, attached my Due-Ramps-FD board, hooked up 4 motors and the two thermistors. I wired the mini USB on RAMPS-FD and connected my computer to it, turned on Repetier Host. Turned on the power supply and POOF! The computer turned off. I freaked out. I removed the battery and I breathed a sign of relief when I connected it back up and it worked......So....I tried another COM port. It did it again. 2nd time I did this was dumb, so a 3rd time would now just be really stupid so I stopped. Somehow the power on the RAMPS-FD board is sending power back to my USB port and shutting down my computer. Does anyone have any idea why or how this can happen? Thank God I was trying the test out with an old laptop. It did not do that before on my desktop. Only difference in setup is that now I have thermistors hooked up. The setup is the same as in my previous post with pictures.
Jaime

Edited 2 time(s). Last edit at 06/18/2015 01:41AM by 3DLTech.

I just downloaded Arduino 1.6.5 and Marlin4Due and it compiled fine.

Sketch uses 116,992 bytes (22%) of program storage space. Maximum is 524,288 bytes.

Is that using windows?

Quote
3DLTech
Is that using windows?

Yes, windows 8.

I have a question for the Due hackers, did anyone address the speed lookup tables?

There are no speed lookups anymore. The Due has hardware division. This is faster.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.

FYI, more work to do, but regarding my LCD issue (12864 Graphic Smart Controller), I have done some more testing . . .

Since the Due and the Mega have the same pinouts to the RAMPS (well, mostly . . . the LCD stuff does not change between them), I put a Mega on my RAMPS-FD (running 1.0.3-dev) to verify LCD function, and that failed. Apparently the pullup resistors on the adapter card doing the level shift are too high to get the timing right. So, I moved the logic level shift circuit to breadboard . . . Same 78HC07 circuit, but with 1K (instead of 10K) pullups, and now the display works with the Mega.

So, back to the Due . . . all I get is garbling on the display, same exact pin assignments and wiring (If I had to guess, I'd say mismatched baud rate, since this interface is serial). To rule out the level transition of the 78HC07, I got a proper 4 channel logic level shifter, and gave that a try. Same gibberish . . . To test further, I took the graphics card test program from U8glib (same tree that Marlin is building against), set it to the same card type that Marlin4Due (or Marlin in general) is using for this display, set the pinning in the test program as per Marlin, and *IT WORKS* . . .

I need to do more testing, but I have pretty much confirmed that my interconnect to the LCD is correct, and that the 1.0.3-dev base Marlin code is not flawed.

Has anything been done in the Due Marlin port that might somehow affect serial port timing? It's not in U8glib, apparently, since the test code from that works . . .

More testing to be done, but if this rings a bell to any of the folks doing the port, please let me know! I'd rather chase unknowns than stuff folks may already know!

Thanks,

- Tim

Well, display problem resolved!!

It looks like the folks who created Marlin added support for the ST7920 Graphic LCD prior to it working very well in U8Glib . . . and thus created their own ST7920 definition for Marlin, located in ultralcd_st7920_u8glib_rrd.h, and creating the display type of U8GLIB_ST7920_128X64_RRD. This works on the Mega, but dies an ugly, garbled death on the Due . . . I suspect that this predates the Due support in U8Glib, and thus the timing for the Due processor just isn't there . . .

I had gotten the display to work with the U8Glib graphic test sample, using type U8GLIB_ST7920_128X64_4X (or 1X . . . they both appear to work).

Looking in Marlin, in dogm_lcd_implemetation.h, this is where the definition of U8GLIB_ST7920_128X64_RRD is made based on a define of U8GLIB_ST7920, coming from the display definition in Conditionals.h.
The good news is that the folks who wrote this didn't break the stock U8Glib type definition . . . Commenting out the ...RRD type definition to U8Glib, and adding a line for U8GLIB_ST7920_128X64_4X compiles cleanly, and *works*!

I had read some notes that hardware SPI did not work on the Due, so all I can think is that this definition knows, and does it in software or some such. The only think that I have not resolved yet is exactly how they are passing the pin definitions to the function in Marlin . . . the old definition had (0,0,0) as arguments, which results in a non-viable config with the library definition. Hard wiring in the pining for the RAMPS-FD as (23,17,16) gets it going well . . . and taking the definitions from pins_XXX.h and inserting to give: U8GLIB_ST7920_128X64_4X u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS); gets past that.

So, bottom line, this ended up looking massive, and took a *one* line change in Marlin, and let's the developers throw away a custom display definition that has apparently been superceded by a native definition in the U8Glib distribution!

@Wurstnass . . . not sure how you want to integrate this into Marlin4Due, or how many folks try to run a graphic LCD on it, but let me know if you need anything else to get this included . . . I think it works around another fundamental difference in the Due and the Mega, and the implementations therof, and thus is important to your port. The basic RepRap 4 line controller works out of the box, for what it's worth . . .

The code snippet from dogm_lcd_implementation.h is at line 120, thus:

#define START_ROW 0

// LCD selection
#ifdef U8GLIB_ST7920
//U8GLIB_ST7920_128X64_RRD u8g(0,0,0);
//U8GLIB_ST7920_128X64_RRD u8g(0)
//Dawson, TPC . . . Get the ST7920 display to actually work on a Due . . .
//U8GLIB_ST7920_128X64_4X u8g(23, 17, 16);
U8GLIB_ST7920_128X64_4X u8g(LCD_PINS_D4, LCD_PINS_ENABLE, LCD_PINS_RS);
#elif defined(MAKRPANEL)
// The MaKrPanel display, ST7565 controller as well
U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0);
#elif defined(VIKI2) || defined(miniVIKI)
// Mini Viki and Viki 2.0 LCD, ST7565 controller as well
U8GLIB_NHD_C12864 u8g(DOGLCD_CS, DOGLCD_A0);
#else

- Tim

Edited 2 time(s). Last edit at 07/07/2015 12:43AM by tadawson.

Hi, I just got an idea...
I recently do RAMPS board compatibility mod. Since neither the original RAMPS board nor Due board have EEPROM, it is impossible to save configurations, unless we use this:

https://github.com/sebnil/DueFlashStorage

Flash memory cycle count limit is rated less than EEPROM, but I think it's a good workaround for modded RAMPS board (other than adding I2C EEPROM).

Quote
Wurstnase
Hi all,

I spend last weeks a lot of time. And now most parts works.
Marlin4Due works with RADDS (also the RADDS-Display with the Back-Button) and also should work with RAMPS-FD V1/V2 (but not tested!).

All the extras which are new in the main-fork are implemented in Marlin4Due.

• Delta Autobedleveling
• up to 4 Extruders
• Filamentsensor
• improved Autobedleveling (G29 RLFB P V) for cartesian printers
• and many other things...

Have fun with it.

Many thanks to bobc for a great starting point!
Also many thanks to all Marlin-developers!

just tried on my due/radds.. no screen, pushing buttons gets a brighter two horizontal flash momentarily...

and conect up with simpyfy gets

Looks like wrong baud rate.

---

Triffid Hunter's Calibration Guide

--> X <-- Drill for new Monitor

Most important Gcode.