Marlin4Due

Re: Marlin4Due

Wurstnase — Fri, 25 Aug 2017 15:52:33 -0400

Looks like wrong baud rate.

Re: Marlin4Due

munchit1 — Tue, 15 Aug 2017 10:35:52 -0400

and conect up with simpyfy gets

Re: Marlin4Due

munchit1 — Tue, 15 Aug 2017 10:32:36 -0400

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. :)-D

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

Re: Marlin4Due

rollingdice — Sat, 19 Mar 2016 12:49:21 -0400

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

Re: Marlin4Due

tadawson — Mon, 06 Jul 2015 21:52:46 -0400

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

Re: Marlin4Due

tadawson — Wed, 24 Jun 2015 16:43:33 -0400

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

Re: Marlin4Due

Wurstnase — Tue, 23 Jun 2015 07:59:25 -0400

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

Re: Marlin4Due

thetazzbot — Mon, 22 Jun 2015 15:07:27 -0400

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

Re: Marlin4Due

thetazzbot — Mon, 22 Jun 2015 15:06:43 -0400

Quote
3DLTech
Is that using windows?

Yes, windows 8.

Re: Marlin4Due

3DLTech — Fri, 19 Jun 2015 23:12:54 -0400

Is that using windows?

Re: Marlin4Due

thetazzbot — Fri, 19 Jun 2015 16:59:57 -0400

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.

Re: Marlin4Due

3DLTech — Thu, 18 Jun 2015 01:39:36 -0400

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

Re: Marlin4Due

Wurstnase — Wed, 17 Jun 2015 09:37:33 -0400

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

Re: Marlin4Due

3DLTech — Wed, 17 Jun 2015 00:35:22 -0400

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

Re: Marlin4Due

3DLTech — Sun, 07 Jun 2015 01:41:51 -0400

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

Re: Marlin4Due

Wurstnase — Fri, 05 Jun 2015 12:27:15 -0400

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. :(

Re: Marlin4Due

Wurstnase — Fri, 05 Jun 2015 03:58:51 -0400

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.

Re: Marlin4Due

Wurstnase — Fri, 05 Jun 2015 02:40:58 -0400

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.

Re: Marlin4Due

3DLTech — Thu, 04 Jun 2015 19:17:09 -0400

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

Re: Marlin4Due

Wurstnase — Thu, 04 Jun 2015 00:26:57 -0400

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.

Re: Marlin4Due

3DLTech — Wed, 03 Jun 2015 21:39:36 -0400

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

Re: Marlin4Due

tadawson — Wed, 03 Jun 2015 20:39:32 -0400

Any chance to look at the inverted fan issue yet?

Thanks,

- Tim

Re: Marlin4Due

AndrewBCN — Wed, 03 Jun 2015 18:58:11 -0400

OK, well done! (tu)

Re: Marlin4Due

Wurstnase — Wed, 03 Jun 2015 18:38:23 -0400

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 :)

Re: Marlin4Due

Wurstnase — Wed, 03 Jun 2015 17:08:15 -0400

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.

Re: Marlin4Due

dc42 — Wed, 03 Jun 2015 16:52:43 -0400

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.

Re: Marlin4Due

Wurstnase — Wed, 03 Jun 2015 15:43:47 -0400

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!?

Re: Marlin4Due

dc42 — Wed, 03 Jun 2015 15:31:14 -0400

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.

Re: Marlin4Due

Wurstnase — Wed, 03 Jun 2015 15:10:11 -0400

@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. :)

Re: Marlin4Due

dc42 — Wed, 03 Jun 2015 14:33:50 -0400

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.