Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Marlin RC-4 (RCBugFix) almost stable! Going final soon! #3154

Closed
Roxy-3D opened this issue Mar 15, 2016 · 73 comments
Closed

Marlin RC-4 (RCBugFix) almost stable! Going final soon! #3154

Roxy-3D opened this issue Mar 15, 2016 · 73 comments
Labels
Needs: More Data We need more data in order to proceed

Comments

@Roxy-3D
Copy link
Member

Roxy-3D commented Mar 15, 2016

This post is just a head up for everybody using Marlin on their 3D-Printers. Release Candidate #4 is getting very stable and the bug reports have dropped off to mostly being support questions. Very soon, we expect to promote RCBugFix to be the new, official, stable release of Marlin. If you know of any issues with RC-4, please let us know about them ASAP!

I've also alerted the users over at RepRap.org and 3DPrintBoard of the status:

http://forums.reprap.org/read.php?415,639920

http://3dprintboard.com/showthread.php?20851-Marlin-RC-4-(RCBugFix)-almost-stable!-Going-final-soon!&p=83325#post83325

PS. A really big Thank You! to ThinkyHead for his taking point on this effort.
@AnHardt
Copy link
Member

AnHardt commented Mar 15, 2016

To finalize fighting the "ok"/buffer problems we need ether #2984 or #3012. #3012 is going better and better now, but my tests are not finished yet (hopefully tonight).

@nickbardom
Copy link

Thanks for the heads up. Any news about the Full Graphics LCD slowness fix?

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 15, 2016

To finalize fighting the "ok"/buffer problems we need ether #2984 or #3012. #3012 is going better and better now, but my tests are not finished yet (hopefully tonight).

We will wait until we hear from you on this topic. Everybody wants this one exactly correct!

@jbrazio
Copy link
Contributor

jbrazio commented Mar 15, 2016

@AnHardt made a good proposal for the LCD speed up but IMHO it's not ready to go into this release.

@Roxy-3D Roxy-3D added the Needs: More Data We need more data in order to proceed label Mar 15, 2016
@paulusjacobus
Copy link
Contributor

@Roxy-3DPrintBoard will try the new RC4 in the weekend on my Mendel and
Corexy printers. I'm curious!

On 16 March 2016 at 04:44, João Brázio notifications@github.com wrote:

@AnHardt https://github.com/Anhardt made a good proposal for the LCD
speed up but IMHO it's ready to go into this release.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#3154 (comment)

@AnHardt
Copy link
Member

AnHardt commented Mar 16, 2016

@jbrazio
Sorry. My lcd_speedup branch is far from ready. For now more a test of concepts. It's good for testing but not for integration. The number_to_string conversions should not be in there (discovered a further conversion in the Serial code - and 4 sprintf_P() to print numbers - never benchmarked sprintf_P() ). The "clock" should be displaied even when SDSUPPORT is not defined, ...
I'll be ready for RC-5 the version after RC4.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 16, 2016

I'll be ready for RC-5 the version after RC4.

I'm starting to think there will be an RC-5 after all. There are more outstanding Pull Requests (with important bug fixes) than I realized.

@jbrazio
Copy link
Contributor

jbrazio commented Mar 17, 2016

Do we have a changelog for this RC version ? I'm not talking about git log more like a high level overview of it.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 17, 2016

No. It's kind of like the documentation issue. We need some help trying to dot all the i's and cross the t's. We don't seem to be very good at documenting things.

@thinkyhead
Copy link
Member

Here's my priority to-do list for release. Basically, critical bug-fixes and obvious bug-fixes should go into RC4, items needing more testing, or experimental PRs can wait. So there are perhaps 4 PRs that I feel should definitely be merged and go into RC4, rather than making users wait for RC5 (definitely the real and final RC!).

The obvious ones are:

These should go into RC4, but need more testing:

The next PR, #3082, would be great to have in RC4 but maybe it's too soon? I'm working on clarifying the documentation in Configuration.h:

I'll do as much testing and integration as I can tonight. Over the next day or two we can take care of any remaining polish needed for RC4. It's not utter perfection, but I feel a lot better about it than RC3!

@jbrazio
Copy link
Contributor

jbrazio commented Mar 17, 2016

If I could add to RC5 wish list it would be automatic mesh leveling as it seems to be a often requested feature. But maybe this can turn out to be a project on its own, I never tried to evaluate the required effort.

We see some questions about the thermal protection which should also be addressed, maybe try out releasing RC4 with the more relaxed default set proposed by @Blue-Marlin as see how it goes on the wild ?

@thinkyhead
Copy link
Member

The Release Process

  • Merge all new commits in RCBugFix onto RC.
  • Update the version and README.md.
  • Tag RC and RCBugFix with the new version.
  • Make a release, listing all the changes since RC3
  • Write up a summary of the version changes for the wiki / documentation site.
  • Go tell two people to tell two people…

@thinkyhead
Copy link
Member

automatic mesh leveling … seems to be a often requested feature

I keep flowcharting things as they are, and this has led to some good insights. Also, collecting all the code corresponding to a feature in one place. I think instead of just focusing on automating Mesh Bed Leveling (though, I kind of want to take a shot at this soon) we should also apply the manual leveling system to the other two leveling equations, following the same model as the current Manual Bed Leveling (that comes with Mesh Bed Leveling), which is very clean. The process of splitting these up conceptually should yield a better system for future expansion.

(We should also investigate how far this kind of work has already progressed in the MarlinDev branches.)

By slotting this feature for 1.1.1 instead of 1.1.0 it frees up the option to "overhaul" the leveling settings, if necessary. –– That's the kind of change that usually deserves a small version bump.

The units we need:

  • A simple system to probe any point and return a relative-Z value.
  • A simple system for the user to manually set a relative-Z at any point.
  • An automated system to: deploy probe, obtain a set of XYZ points, stow probe.
  • A manual system to: Move to XY points, ask the user to adjust and set Z at each.
  • When all points are collected, they are fed to the equation chosen by the user: Mesh, Grid, 3-point…

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 17, 2016

I get confused easily. But I think I'm hearing you say that Automatic Mesh Bed Leveling that is not even fully written yet is way too big, complicated and untested to sneak into a Release Candidate. If that is what you are saying, I'm in agreement.

@thinkyhead
Copy link
Member

Change Log for Marlin 1.1.0-RC4 – as compared to RC3

CoreXY and CoreXZ:

Hosts, GCode:

LCD Controllers and SD cards:

Minor bugs:

Homing, Bed Leveling:

New and Experimental Features:

Configurations:

And...

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 19, 2016

That is an impressive list of changes! For RC-5, let's commit to only making changes that fix bugs. We need to get things to stabilize.

@paulusjacobus
Copy link
Contributor

@thinkyhead RC3 seems to work extremely well for me. So I'm happy to move to RC-4 and start testing.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 20, 2016

@thinkyhead RC3 seems to work extremely well for me. So I'm happy to move to RC-4 and start testing.

We need 20x of you.

@paulusjacobus
Copy link
Contributor

@Roxy-3DPrintBoard We need 20x of you.
<
I have 3 printers... 2 Prusa I2s and one CoreXY (I'm building it, 90% complete)
Does that mean I count for 3 testers...hummm probably not

@AnHardt
Copy link
Member

AnHardt commented Mar 20, 2016

Todays RCBugFix(32f7574) feels very well. It only needs #3186, #3187 to be good enough for a release.

For #3182 (Add support for Printrboard RevF) i see low potential to break something else.
#3113 (Stop print timer with M105/M109) looks ok, but i don't see all consequences. I'd not feel well with merging right now before release or i need some more days to test.
#3082 (Check probes only when deployed) was part of a bigger endstop-master-plan i made 5 month ago. Right now i have no clue about the consequences when merged alone.
#3065 (Simplified endstop configuration) is also a candidate for the next round- like some other endstop stuff.
#3069 (Delta-compatible extensions to M48) needs confirmation to work, from at least one additional tester with a DELTA.
EDITED

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 20, 2016

#3069 (Delta-compatible extensions to M48) needs confirmation to work, from at least one additional tester with a DELTA.

It actually needed changes to handle Cartesian Machines also. We need a couple of Cartesian Machines to load it and give a Thumbs Up.

#3082 (Check probes only when deployed) was part of a bigger endstop-master-plan i made 5 month ago. Right now i have no clue about the consequences when merged alone.

This one feels important to get included just because so many machines are now having probes that are triggered when they are stowed. Can we get this one checked out to see if it can be included? Ideally, we would want to verify that neither the triggered or not triggered state does not have any impact when the probe is stowed.

@epatel
Copy link
Contributor

epatel commented Mar 20, 2016

@thinkyhead Note about the list. I see #2978: Apply Mesh Bed Leveling matrix when switching extruders. But when looking at #2978 its about ABL.

@AnHardt
Copy link
Member

AnHardt commented Mar 20, 2016

@Roxy-3DPrintBoard
The importance of #3082, or what ever number it had 5 month ago has not changed, for me, since then. If it had been important enough for you, or anyone else, it would have been tested and merged then. :-(
My hope that anyone (but me) will test this before merged in, decreased to zero. Merging it in, just before the release, makes no sense to me.

@thinkyhead
Copy link
Member

@epatel I will double-check the titles I gave to the PRs. I generated the original list using some command piping and regex in BASH and it may have munged some of the number-title correspondences.

@thinkyhead
Copy link
Member

#3082 was one of those I was on the fence about. The description it included convinced me it was well thought out, pretty well constrained, and relatively straightforward. I couldn't find any fault with the logic in the code itself. And there are a couple of issues it would seem to address even beyond its immediate target,

For me the question was whether it was better to get it into the hands of users or to leave the issue of unwanted probe readings unaddressed in RC4. My confidence level is about 80% that the idea will work like a charm. The 20% I hold in reserve is for spots where it may yet need to be applied. But we can take a closer methodical look at it and see how we feel in toto.

But let me ask @AnHardt … How do you feel about #3082 and adding the new Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and FIX_MOUNTED_PROBE settings? Do you also think it must be possible to simplify this mess of multiplying probe and endstop options? Should we hold off and think it through more before committing to the techniques from #3082?

Anyway, I'm giving another day or two to see what shakes out of RCBugFix, and if we feel that nothing is too egregious, I will aim to release RC4 on March 23.

@jbrazio
Copy link
Contributor

jbrazio commented Mar 21, 2016

@thinkyhead will this be the last RC or do you plan for another round ?

@thinkyhead
Copy link
Member

@jbrazio If RC4 can survive a week without getting flagged with any "serious" bugs, it might end up being the final release. But, if we end up fixing any "tricky" issues, we may want to do just one more RC# with a very short and constrained patch cycle, Either RC4 or the RC5 will definitely be the official release, and I would like to aim for April 1st, no fooling.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 21, 2016

But let me ask @AnHardt … How do you feel about #3082 and adding the new Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and FIX_MOUNTED_PROBE settings? Do you also think it must be possible to simplify this mess of multiplying probe and endstop options? Should we hold off and think it through more before committing to the techniques from #3082?

I think there is a lot of room for debate on this. All opinions are welcome and deserve to be considered. But the way I'm coming at it, if a probe is not deployed (or engaged), the values it returns should not be looked at or used. That is kind of independent of how we make it easier for the user. And really... This seems like a good point in time for somebody to introduce a Probe Object. (But NOT in the Release Candidate) We don't even need one object that handles all cases. We just need to be able to select which probe object (fixed, manually deployed, kicked down with a servo, Z-Min EndStop, etc.) that is going to be used.

@thinkyhead will this be the last RC or do you plan for another round ?

With this many changes... My guess is the odds of us not seeing some bad behavior in RC-4 is low.

@AnHardt
Copy link
Member

AnHardt commented Mar 21, 2016

But let me ask @AnHardt … How do you feel about #3082 and adding the new Z_MIN_PROBE_USES_Z_MIN_ENDSTOP_PIN and FIX_MOUNTED_PROBE settings? Do you also think it must be possible to simplify this mess of multiplying probe and endstop options? Should we hold off and think it through more before committing to the techniques from #3082?

As far i can read my own messages above i said, 'part of a bigger plan' and 'not right now'.
However - it works for me like a charm. But i know what to configure for my needs.

Of course. That area needs simplification. Especially the old descriptions are more confusing than enlightening the matter. Some of the options can be avoided at all. The right grouping seems to be important

To get an impression of my plan:

The logic has to be reversed from
No ABL -> No probe
to
No probe -> No ABL

Do we have a probe?
If not we use one of the Z endstop-pins for normal homing and can probe manually only.
If yes, we have to define where it is connected.
Ether at a dedicated probe pin.
PROBE_USES_PROBE_PIN
// that implies we also have at least one Z endstop that will be used for homing
or
PROBE_USES_Z_MIN_ENDSTOP_PIN
// implies we use the probe also for homing, if homing to z-min, and use Z_SAFE_HOMING

Than we can define one kind if probe.

  • Manual
  • Fix mounted
  • Servo
  • Sled
  • Allen Key
  • Tilt (Not for homing - needs to know z for deploying - or luck)
  • User defined

Per probe type there could be predefined selections of probe actions - maybe in separate files.
They build a sequence. Each of them can be omitted.
//// deploy()
// store x,y

  • Sequence of moves to be save to deploy (MIN_HEIGHT_FOR_PROBE_HANDLING)
  • Test if already deployed. (triggered when stowed) - skip
  • Sequence of moves to actually deploy the probe (Allen Key, sled, tilt)
  • Set servo angle.
  • Set solenoid pin.
  • Manual deploy (wait for click).
  • Test if deployed now (triggered when stowed) - repeat - error
    // return to x,y
    // activate pin testing

//// probe()

  • go down until the probe triggers
  • touch touch
  • Manual probe (adjust height - wait for click)

//// refresh for 'E'()

  • complete stow
  • complete deploy
  • Set servo angle.
  • Set solenoid pin.

//// stow()
// deactivate pin testing
// store x,y

  • Sequence of moves to be save to deploy (MIN_HEIGHT_FOR_PROBE_HANDLING)
  • Test if already stowed. (triggered when stowed) - skip
  • Sequence of moves to actually stow the probe (Allen Key, sled, tilt)
  • Set servo angle.
  • Set solenoid pin.
  • Manual stow (wait for click).
  • Test if deployed now (triggered when stowed) - repeat - error

// return to x,y

If the probe is an object or not, does not matter. We need 4 functions/methods (deploy, probe, refresh, stow). All ending at the same x/y they started. Than probe handling for the calling function is trivial.

Targets:

  • Simplification by generalization.
  • Printing without ENDSTOPS_ONLY_FOR_HOMING

@jbrazio
Copy link
Contributor

jbrazio commented Mar 26, 2016

Makes sense your suggestion, what we have now might be named "assisted manual leveling" as Marlin is assisting you to go trough points.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 26, 2016

You don't really need to drive the head through a sequence of positions, as
long as it can be pushed around without changing z POS. It also means you
don't need to know the adjuster geometry in the software.

I think it is very common to have a 'Problem Area' on your bed and/or Mesh. Being able to adjust and edit the Mesh for these areas is important. One thing I'm looking at is allowing the adjustment of any random point as opposed to the actual Mesh Points. By doing a Bi-linear correction to the four points around the random position being corrected, it may be possible to push and pull the Mesh into the correct shape easier.

@thawkins
Copy link
Contributor

Sounds like something better solved with a bit of glass.
On Mar 27, 2016 12:24 AM, "Roxy-3DPrintBoard" notifications@github.com
wrote:

You don't really need to drive the head through a sequence of positions, as
long as it can be pushed around without changing z POS. It also means you
don't need to know the adjuster geometry in the software.

I think it is very common to have a 'Problem Area' on your bed and/or
Mesh. Being able to adjust and edit the Mesh for these areas is important.
One thing I'm looking at is allowing the adjustment of any random point as
opposed to the actual Mesh Points. By doing a Bi-linear correction to the
four points around the random position being corrected, it may be possible
to push and pull the Mesh into the correct shape easier.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 26, 2016

Sounds like something better solved with a bit of glass.

This might be true on a Cartesian printer. But for a Delta, a perfectly flat piece of glass won't fix the issues. And besides... It's a fun piece of code to write!

@thinkyhead
Copy link
Member

what an absolute torture to flash the board

@paulusjacobus Sounds like something we should add to the new documentation. We need a page for each board that we support, probably, just to explain the quirks. PB RevF sounds like one of the more quirky ones.

@thinkyhead
Copy link
Member

I've been at 2 degrees in 20 seconds for a long time. Anything tighter trips the protection.

There probably needs to be a longer initial period, when the hot-end is more cold, then after that, the heating speed may tend to increase. Ideally it would be nice to automate this tuning, like M303, so the machine knows what its heating profile "should" look like, and then it could give some leeway, but not too much.

Anyway, I will relax it to 2 degrees in 20 seconds, which should be more than enough time even initially. (#3262)

@thawkins
Copy link
Contributor

I have noticed that the PID as it approaches the set temp, can
significantly slow down heating and even reverse before picking back up
again. Would that not potentially trigger the protection.
On Mar 27, 2016 10:00 PM, "Scott Lahteine" notifications@github.com wrote:

I've been at 2 degrees in 20 seconds for a long time. Anything tighter
trips the protection.

There probably needs to be a longer initial period, when the hot-end is
more cold, then after that, the heating speed may tend to increase. Ideally
it would be nice to automate this tuning, like M303, so the machine knows
what its heating profile "should" look like, and can give some leeway, but
not too much.

Anyway, I will relax it to 2 degrees in 20 seconds, which should be more
than enough time even initially.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@thinkyhead
Copy link
Member

A well-tuned PID shouldn't fall back too far. Anyway, as soon as the heating is within the "hysteresis" range, the WATCH_TEMP test turns off.

@StephS
Copy link
Contributor

StephS commented Mar 28, 2016

@paulusjacobus The Printrboard does not use the PJRC bootloader, thus the necessity for Atmel FLIP to be installed to flash. The teensyduino libraries are required for the MCU to function since Arduino never added official support for the AT90USB1286. The Reprap wiki has full instructions on how to flash the Printrboard ( Linux and Mac support is limited at the moment).
The remaining issue for Printrboard support is a nuisance more than anything, it utilizing marlin pin mapping for everything except the SPI pins, which it reverts to Teensyduino pin mapping. Part of this issue is that the Teensyduino library uses non-standard pin mapping.

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 28, 2016

@StephS How much work would it be to get the PrintRboard cleaned up and working well with Marlin?

@StephS
Copy link
Contributor

StephS commented Mar 28, 2016

You mean changes to the physical board? or to Marlin? Support is added and thinkyhead merged. The issues were minor, like pin configuration and support for the DAC. The real issue is that Arduino does not natively support the AT90USB1286. You would need to develop and push a new library to Arduino, and even then you wouldn't have native programming. The AT90USB uses native USB instead of FTDI or another MCU, so special software is required to program, or programming a new bootloader (experimental). Since there is a lot of risk in programming the bootloader, it's better to use Atmel FLIP.
The options are limited and complicated. Nobody wants to write and maintain a library from scratch, write a DFU loader from scratch, or risk bricking with a new bootloader.

@thawkins
Copy link
Contributor

My understanding is that the official boards from Printrbot use the DFU
bootloader, whereas the clones from places like geeetech use the CDC
bootloader.

Both bootloaders require a jumper to be installed and reset to initiate
bootloading. While the use of FLIP is one way of flashing the boards, it
is not the most common way of doing it.
On Mar 29, 2016 6:48 AM, "Stephanie" notifications@github.com wrote:

@paulusjacobus https://github.com/paulusjacobus The Printrboard does
not use the PJRC bootloader, thus the necessity for Atmel FLIP to be
installed to flash. The teensyduino libraries are required for the MCU to
function since Arduino never added official support for the AT90USB1286.
The Reprap wiki has full instructions on how to flash the Printrboard (
Linux and Mac support is limited at the moment).
The remaining issue for Printrboard support is a nuisance more than
anything, it utilizing marlin pin mapping for everything except the SPI
pins, which it reverts to Teensyduino pin mapping. Part of this issue is
that the Teensyduino library uses non-standard pin mapping.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@thawkins
Copy link
Contributor

Can you not use PlatformIO, which does support the chipset with the
Arduino framework?
On Mar 29, 2016 7:16 AM, "Stephanie" notifications@github.com wrote:

You mean changes to the physical board? or to Marlin? Support is added and
thinkyhead merged. The issues were minor, like pin configuration and
support for the DAC. The real issue is that Arduino does not natively
support the AT90USB1286. You would need to develop and push a new library
to Arduino, and even then you wouldn't have native programming. The AT90USB
uses native USB instead of FTDI or another MCU, so special software is
required to program, or programming a new bootloader (experimental). Since
there is a lot of risk in programming the bootloader, it's better to use
Atmel FLIP.
The options are limited and complicated. Nobody wants to write and
maintain a library from scratch, write a DFU loader from scratch, or risk
bricking with a new bootloader.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@paulusjacobus
Copy link
Contributor

I had a look at PlatformIO which supports the Arduino (Mega) and Teensy
(AT90USB) hardware and libraries (i.e. U8Glib). So, It looks very promising
from a first browse on the website. I will download and install it and see
if it works (compiles) with Marlin

On 29 March 2016 at 10:32, Tim Hawkins notifications@github.com wrote:

Can you not use PlatformIO, which does support the chipset with the
Arduino framework?
On Mar 29, 2016 7:16 AM, "Stephanie" notifications@github.com wrote:

You mean changes to the physical board? or to Marlin? Support is added
and
thinkyhead merged. The issues were minor, like pin configuration and
support for the DAC. The real issue is that Arduino does not natively
support the AT90USB1286. You would need to develop and push a new library
to Arduino, and even then you wouldn't have native programming. The
AT90USB
uses native USB instead of FTDI or another MCU, so special software is
required to program, or programming a new bootloader (experimental).
Since
there is a lot of risk in programming the bootloader, it's better to use
Atmel FLIP.
The options are limited and complicated. Nobody wants to write and
maintain a library from scratch, write a DFU loader from scratch, or risk
bricking with a new bootloader.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
#3154 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@emartinez167
Copy link
Contributor

I can confirm it works with mega.
On Tue, 29 Mar 2016 at 10:48, paulusjacobus notifications@github.com
wrote:

I had a look at PlatformIO which supports the Arduino (Mega) and Teensy
(AT90USB) hardware and libraries (i.e. U8Glib). So, It looks very promising
from a first browse on the website. I will download and install it and see
if it works (compiles) with Marlin

On 29 March 2016 at 10:32, Tim Hawkins notifications@github.com wrote:

Can you not use PlatformIO, which does support the chipset with the
Arduino framework?
On Mar 29, 2016 7:16 AM, "Stephanie" notifications@github.com wrote:

You mean changes to the physical board? or to Marlin? Support is added
and
thinkyhead merged. The issues were minor, like pin configuration and
support for the DAC. The real issue is that Arduino does not natively
support the AT90USB1286. You would need to develop and push a new
library
to Arduino, and even then you wouldn't have native programming. The
AT90USB
uses native USB instead of FTDI or another MCU, so special software is
required to program, or programming a new bootloader (experimental).
Since
there is a lot of risk in programming the bootloader, it's better to
use
Atmel FLIP.
The options are limited and complicated. Nobody wants to write and
maintain a library from scratch, write a DFU loader from scratch, or
risk
bricking with a new bootloader.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<

#3154 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
#3154 (comment)

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3154 (comment)

@thawkins
Copy link
Contributor

There is a platformio support folder on RC4 which I belive has a definition
for the printrboard.

I normally use a ramps card, so to compile and upload to my card

cd PlatformioAddons
platformio run -e mega2560 -t upload

The value after the -e is the environment name, which is one of the listed
environments inside the platformio.ini file inside the add-ons folder.

-t upload

Tells it to upload after compiling, if you leave that off it just compiles
without uploading. There is a platformio IDE which is a plug-in based on
the Atom editor, which completely blows away the arduino environment as far
as useability is concerned.
On Mar 29, 2016 10:48 AM, "paulusjacobus" notifications@github.com wrote:

I had a look at PlatformIO which supports the Arduino (Mega) and Teensy
(AT90USB) hardware and libraries (i.e. U8Glib). So, It looks very promising
from a first browse on the website. I will download and install it and see
if it works (compiles) with Marlin

On 29 March 2016 at 10:32, Tim Hawkins notifications@github.com wrote:

Can you not use PlatformIO, which does support the chipset with the
Arduino framework?
On Mar 29, 2016 7:16 AM, "Stephanie" notifications@github.com wrote:

You mean changes to the physical board? or to Marlin? Support is added
and
thinkyhead merged. The issues were minor, like pin configuration and
support for the DAC. The real issue is that Arduino does not natively
support the AT90USB1286. You would need to develop and push a new
library
to Arduino, and even then you wouldn't have native programming. The
AT90USB
uses native USB instead of FTDI or another MCU, so special software is
required to program, or programming a new bootloader (experimental).
Since
there is a lot of risk in programming the bootloader, it's better to
use
Atmel FLIP.
The options are limited and complicated. Nobody wants to write and
maintain a library from scratch, write a DFU loader from scratch, or
risk
bricking with a new bootloader.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<

#3154 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
<
#3154 (comment)

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 29, 2016

Thank You for the extra PrintRBoard information! The reason I'm asking is my first printer has a PrinteRBoard in it. I just wanted to know if I needed to be aware of anything. PrintRBoard's have always had a problem of not being supported well by Arduino. I got v.1.05 going with my board but I now need to get moved to the latest Arduino since we are going to start enforcing its use (because of suspected compiler bugs).

@thawkins
Copy link
Contributor

The arduino framework inside platformio is based on 1.6.7, the compilers
are the same ones or later than those distributed with the Arduino
version.
On Mar 29, 2016 8:37 PM, "Roxy-3DPrintBoard" notifications@github.com
wrote:

Thank You for the extra PrintRBoard information! The reason I'm asking is
my first printer has a PrinteRBoard in it. I just wanted to know if I
needed to be aware of anything. PrintRBoard's have always had a problem of
not being supported well by Arduino. I got v.1.05 going with my board but I
now need to get moved to the latest Arduino since we are going to start
enforcing its use (because of suspected compiler bugs).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@StephS
Copy link
Contributor

StephS commented Mar 29, 2016

I had a look at the platformIO definition, there would need to be another entry for the RevF board since the pin use changed from the other rev boards.

@thawkins
Copy link
Contributor

You have to select a different board I belive, board no 811 vs 81 for the
Rev D. You could just duplicate the printrboard entry and create one
called printrboardrevf that has the right board define,

Here is the snippet from boards.h that has the relevant stuff

#define BOARD_PRINTRBOARD 81 // Printrboard (AT90USB1286)
#define BOARD_PRINTRBOARD_REVF 811 // Printrboard Revision F
On Mar 29, 2016 11:22 PM, "Stephanie" notifications@github.com wrote:

I had a look at the platformIO definition, there would need to be another
entry for the RevF board since the pin use changed from the other rev
boards.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@paulusjacobus
Copy link
Contributor

@Roxy-3DPrintBoard I managed to compile the Marlin code for Rev F without
issues.

On 29 March 2016 at 23:37, Roxy-3DPrintBoard notifications@github.com
wrote:

Thank You for the extra PrintRBoard information! The reason I'm asking is
my first printer has a PrinteRBoard in it. I just wanted to know if I
needed to be aware of anything. PrintRBoard's have always had a problem of
not being supported well by Arduino. I got v.1.05 going with my board but I
now need to get moved to the latest Arduino since we are going to start
enforcing its use (because of suspected compiler bugs).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@Roxy-3D
Copy link
Member Author

Roxy-3D commented Mar 29, 2016

I managed to compile the Marlin code for Rev F without issues.

@paulusjacobus With which version of the compiler? Hopefully, with the latest v.1.6.8 !

@paulusjacobus
Copy link
Contributor

@Roxy-3DPrintBoard Yes version 1.6.8 and I even have installed 1.6.9 but
not tried that with the Rev F board.

On 30 March 2016 at 10:03, Roxy-3DPrintBoard notifications@github.com
wrote:

I managed to compile the Marlin code for Rev F without issues.

@paulusjacobus https://github.com/paulusjacobus With which version of
the compiler? Hopefully, with the latest v.1.6.8 !

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#3154 (comment)

@Grogyan
Copy link
Contributor

Grogyan commented Apr 2, 2016

One query I have with the firmware,
If you are using a smart display and also have the printer connected to a host computer.
Is there a way to let the host know that you have started a preheat/cooldown from the smart display?

@Blue-Marlin
Copy link
Contributor

All needed info is in the answer to M105. All the host has to do, is to evaluate that info.

@thinkyhead
Copy link
Member

As we're onto patching RC5 towards RC6 (no doubt the final RC) this can close.

@AnHardt AnHardt mentioned this issue May 4, 2016
Closed
@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Apr 10, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Needs: More Data We need more data in order to proceed
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests