Testers NEEDED

[boelle]

We are in the process of getting the issues list down to 0, or as close we can.

For this we need a lot of people, with as much different machine setups as we can, that are willing to load the latest development and report back any faults, the goal is not to do features but just to test for faults.

Testers so far:

@MagoKimbra - one Prusa I3 with Ramps 1.4 and 4 extruder and autobed level with servo & one Kossel mini with ramps 1.4.

@a4jp-com - Scoovo X9H

@darkjavi - PrusaI3 with megatronics V2 & coreXY printer with ramps1.4

@fmalpartida - H-Bot mechanics (with auto level) and AT90USB1286 controller

@gregrebholz - Rumba on RigidBot

@avluis - MakerFarm Prusa i3v 12" - RAMBo w/heated bed & dual extrusion (Dual Hexagon set-up for > 300C), ABL (servo+micro switch), LCD + SD (RepRapDiscount Full Graphic Display).

@vandarin - Phoenix with RAMBo, 1 extruder, heated bed, switch touch probe

@Grogyan - RAMPS 1.2 derivative with on board MAX6675 & test bed electronics is RAMPS 1.4 with a RepRap discount full graphic display, Max6675

@thawkins - Scratch built machine with autoleveling inductive probe, ramps, 330x200 bed, based on zentoolworks cnc chassis, dual jhead hotend, qubd thermistors. Ballscrews. Reprap discount Full graphic display. Heatbed. & Scratch built machine with autoleveling servo and microswitch, ramps, 210x210 bed, jonbot, printed chassis. Single ubis hotend, qubd thermistors. Gt2 belts. Reprap discount 20x4 display. Heatbed.

@arno-millenaar - Rumba with external DM422C drivers (will add the extra delay in the stepper code)
LCD + SD (RepRapDiscount Smart Controller)
Bed Auto-Leveling
Bulldog XL Extruders with E3D v6 hotends (not sure this is relevant :) ) setup for > 300C
Bed 500W with temperature reach of 185C (or more not tested)
Thermistor for Bed and Thermocouples (AD597) for the hotends

@Lukelectro - I have a Mendel90 (Melzi electronics), gt2 belts and modified (low power, run a 24V hotbed on 12V) hotbed, otherwise standard)

@pacaj2am - Rebelix with Ramps 1.4 and Heated Bet.

@JoshyuNL - MendelMax 1.5 custom, Rambo 1.3, Heated bed + dual extruder, Filament Diameter Sensor

@alhirzel - modified MTU MOST delta printer on Sanguinololu 1.3a

@thinkyhead - Prusa i3 with Mega2560, RAMPS 1.4, Gadgets3D (HD44780-based) 20x4 LCD. &
Custom Deltabot with a Brainwave board.

@Booli CreatrHS

@CONSULitAS Vellemann K8200

@PxT Printrbot Simple Metal, Revision D board

@ProjectEnder Rostock, RAMPS 1.4, 1 Extruder, J-Head HotEnd, Nichrome Wire Heated Bed, RepRapDiscount Full Graphic Display Smart, and Filament Diameter Sensor

@clefranc Prusa i3 EiNSTeiN Variant, RAMPS 1.4, Dual Extruder, J-Head Hotend, Heated Bed, RRD Fan Extender, Filament Diameter Sensor, RepRapDiscount Smart LCD Controller or RepRapDiscount Full Graphic Smart LCD Controller

Boots Industries BI V2.5 (Delta), RUMBA, Dual Bowden Extruder, Pico Hotend, 500°C Thermistor, Heated Bed, RepRapDiscount Full Graphic Smart LCD Controller

@boelle Mendel90 Sturdy version. OMC Board w/DSM Drivers

@Natealus Modified Rostock Max V2, 280 mm circular diameter X 360mm height, E3D Kraken 4 nozzle hotend, M3 screw-in thermistors, water pump for Kraken, 4 Airtripper V3 BSP Extruders slightly modified, Onyx 120C Heated Bed, borosilicate glass print surface, Azteeg X3 Pro Printer Controller, servo z-probe, and Viki 2 Graphical LCD.

@Sniffle 12" Makerfarm Prusa i3V, Rambo Electronics, bed auto-leveling with servo and switch, RepRap Discount full graphics Display, E3DV6 Dual extruder

Test object: http://www.thingiverse.com/thing:525888

[boelle]

This is just a place holder message for now, disregard this message for now

@MagoKimbra @a4jp-com @darkjavi @fmalpartida @gregrebholz @avluis @vandarin @Grogyan @thawkins @arno-millenaar @Lukelectro @pacaj2am @JoshyuNL @alhirzel @thinkyhead @Booli @CONSULitAS @PxT @ProjectEnder

How well does the current code work ?

Latest Code

https://github.com/MarlinFirmware/Marlin/archive/Development.zip

Use latest NON-Beta of Arduino IDE to compile

[fmalpartida]

Hi folks,

I've been trying out the latest development branch and it is almost good to go into the integration branch. The reason for not qualifying yet is that the refresh of the position which it is printing it shows all "---". It looks like something that @thinkyhead may have introduced while sorting out the positioning in the LCD.

Apart from that, prints look good.

I would also like to encourage people to start taking on the integration branch for testing to get it ready for promotion to release.

The last item is, how do we promote developments into the integration branch for further testing?

[clefranc]

@fmalpartida I agree with you, the integration branch need to be promoted. There is some outstanding issues that need to be addressed once there.

Personally, I wish to see the next release the safest as possible, ie thermal runaway finalized, ABL secured, delta motions fixed, etc. Is the integration branch the right place to do this or it must be nailed down in the development branch first?

Are the new features asked being integrated one by one, or what will be done in the development branch at the time will go directly to the next integration?

@boelle A lot have been done since the last release, is it going to be a release note?

Is there going to be new labels and milestones for the integration branch? Did we need to report bugs and do comments with an [Integration] tag?

Sorry for asking to many questions (some already answered), but there must be new guidelines for testers and I don't want anyone (me first) spend valuable coders time with inappropriate reports or requests.

[thinkyhead]

the position which it is printing it shows all "---"

Even during printing? How strange. It uses axis_known_position[] to decide to show that, and when printing those must always be true.

[thinkyhead]

integration branch need to be promoted

Can we confirm that bed auto leveling is now working reliably?

[thinkyhead]

new labels and milestones for the integration branch?

The integration branch will be developer-centric, and any bugs found there will also exist in Development – or will at least be worked on within Development. The code freeze has gone a long way towards giving us a more bug-free basis. I don't think we'll need new milestones connected to Integration per se. I think we can continue to focus on bugs and issues themselves in the same focused way, and use Integration to pull in things that seem to work.

[fmalpartida]

Autoleveling in my core XY is working reliably, no worries there. I need to check a couple of things since the test print didn't come out as I expected but it may be due to the confirmation I used to print.
For the use of branches and where to freeze things I will share my thoughts later on. I am trying to see what is the most effective way to use the Intel branch to bring it to a promotion level.

[fmalpartida]

Sorry, forgot to mention, yes during prints with autoleveling active.

[thinkyhead]

Well, I guess the most proper way is to make branches for staging features instead of using Development, and bring them to Integration as they prove fit, resolving conflicts at merge time. Presumably if everything is done this way it minimizes conflicts. Then the Development branch becomes just another staging platform, or loses its corona. The only problem I have with multiplying branches is that I already do that in my fork, and so really, we could just keep doing new features within forks, and get testers to pull from there.

[fmalpartida]

Hi folks,

just reporting back from the last tests today, the current development branch is broken. Download to the board, tried testing but I don't get any feedback on the serial interface. It is not looking very healthy.

I was hoping to try it out to see if we could promote it to integration but unfortunately not.

[thinkyhead]

@fmalpartida Sorry, my bad. I tested my code before merging it in, but a last-second change slipped in a bug. It should be ok now.

[fmalpartida]

I'll give it a shot this morning. Thanks dude.

[fmalpartida]

@thinkyhead still not playing ball the development branch:
< echo:Unknown command: "N"
< echo:Unknown command: "N"
< echo:Unknown command: "N"
< echo:Unknown command: "N"
< echo:Unknown command: "N"
< echo:Unknown command: "N"
< echo:Unknown command: "N"

Cura returning all this...

[clefranc]

@fmalpartida I'm printing with #2142, don't have issue with "N" command. Which version are you using?

I look forward for a better versionning for testers, there is already works in progress, I'm eager to see how it'll implemented. Perhaps display the build number on the LCD splash screen, or something that can identify the Github version easily.

[fmalpartida]

Using the latest dev branch.

[fmalpartida]

Printing from cura.

[thinkyhead]

It might still be barking about M110 or some other non-standard command. If it's still happening now, I will try doing some testing with Cura and see what GCode it's sending.

[github-actions]

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.