FLSUN from AliExpres

How do you set a buffer in Repetier-host?

The Marlin-AC version I posted here compiles error and warning free.

I'm using the firmware provided by FLSUN (ver 1.0.0).
Arduino compiles it without any errors.

The USB connection still isn't stable.
The receive and send buffer (devicemanager) was on max (14 and 16) so that should be OK.
I even tried lower buffer size but that didn't make things worse or better.

Another thing I tried was to set the Windows priority of 'RepetierHost.exe' to 'High' or even 'Realtime' but that didn't work eighter.

I have the printer running on SD card now.
Seems it could't work with the 8GB sd card I was using.
Replaced the 8Gb SD with an 4GB SpeedClass 2 and now it prints without stalling.

Is it possible to get a copy of that firmware? Mines gives int convert to char errors.....

Thanks

The firmware provided by FLsun gives some 'convert to char' warnings if compiled with the latest Arduino software; it didn't if compiled with the old Arduino provided by FLsun. I fixed those warnings as well in the Marlin-AC firmware in my previous post; which is basically the FLsun firmware, warning free and with an extra G33 auto calibration function added to it.

Edited 1 time(s). Last edit at 04/03/2016 11:05AM by LVD.

Well I downloaded the firmware and tried to compile it in 1.6.6 and I get the following erros:

Arduino: 1.6.6 (Windows 10), Board: "Arduino/Genuino Mega or Mega 2560, ATmega2560 (Mega 2560)"

sketch\Marlin_main.cpp:1726:32: warning: extra tokens at end of #ifdef directive [enabled by default]

#ifdef ENABLE_AUTO_CALIBRATION && DELTA

^

sketch\Marlin_main.cpp:2422:36: warning: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wliteral-suffix]

LCD_MESSAGEPGM(MACHINE_NAME" "MSG_OFF".");

^

Marlin_main.cpp:254: error: 'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

float bed_level[AUTO_BED_LEVELING_GRID_POINTS][AUTO_BED_LEVELING_GRID_POINTS];

^

Marlin_main.cpp:254: error: 'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

float bed_level[AUTO_BED_LEVELING_GRID_POINTS][AUTO_BED_LEVELING_GRID_POINTS];

^

sketch\Marlin_main.cpp: In function 'void set_bed_level_equation(float, float, float)':

Marlin_main.cpp:871: error: 'ABL_PROBE_PT_1_X' was not declared in this scope

vector_3 xLeftyFront = vector_3(ABL_PROBE_PT_1_X, ABL_PROBE_PT_1_Y, z_at_Pt1);

^

Marlin_main.cpp:871: error: 'ABL_PROBE_PT_1_Y' was not declared in this scope

vector_3 xLeftyFront = vector_3(ABL_PROBE_PT_1_X, ABL_PROBE_PT_1_Y, z_at_Pt1);

^

Marlin_main.cpp:872: error: 'ABL_PROBE_PT_2_X' was not declared in this scope

vector_3 xLeftyBack = vector_3(ABL_PROBE_PT_2_X, ABL_PROBE_PT_2_Y, z_at_Pt2);

^

Marlin_main.cpp:872: error: 'ABL_PROBE_PT_2_Y' was not declared in this scope

vector_3 xLeftyBack = vector_3(ABL_PROBE_PT_2_X, ABL_PROBE_PT_2_Y, z_at_Pt2);

^

Marlin_main.cpp:873: error: 'ABL_PROBE_PT_3_X' was not declared in this scope

vector_3 xRightyFront = vector_3(ABL_PROBE_PT_3_X, ABL_PROBE_PT_3_Y, z_at_Pt3);

^

Marlin_main.cpp:873: error: 'ABL_PROBE_PT_3_Y' was not declared in this scope

vector_3 xRightyFront = vector_3(ABL_PROBE_PT_3_X, ABL_PROBE_PT_3_Y, z_at_Pt3);

^

sketch\Marlin_main.cpp: In function 'void extrapolate_one_point(int, int, int, int)':

Marlin_main.cpp:1108: error: 'bed_level' was not declared in this scope

if (bed_level[x][y] != 0.0) {

^

Marlin_main.cpp:1111: error: 'bed_level' was not declared in this scope

float a = 2*bed_level[x+xdir][y] - bed_level[x+xdir*2][y]; // Left to right.

^

sketch\Marlin_main.cpp: In function 'void extrapolate_unprobed_bed_level()':

Marlin_main.cpp:1128: error: 'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

int half = (AUTO_BED_LEVELING_GRID_POINTS-1)/2;

^

sketch\Marlin_main.cpp: In function 'void print_bed_level()':

Marlin_main.cpp:1142: error: 'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

for (int y = 0; y < AUTO_BED_LEVELING_GRID_POINTS; y++) {

^

In file included from sketch\Marlin_main.cpp:30:0:

Marlin_main.cpp:1144: error: 'bed_level' was not declared in this scope

SERIAL_PROTOCOL_F(bed_level[x][y], 2);

^

sketch\Marlin.h:63:48: note: in definition of macro 'SERIAL_PROTOCOL_F'

#define SERIAL_PROTOCOL_F(x,y) (MYSERIAL.print(x,y))

^

sketch\Marlin_main.cpp: In function 'void reset_bed_level()':

Marlin_main.cpp:1153: error: 'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

for (int y = 0; y < AUTO_BED_LEVELING_GRID_POINTS; y++) {

^

Marlin_main.cpp:1155: error: 'bed_level' was not declared in this scope

bed_level[x][y] = 0.0;

^

exit status 1
'AUTO_BED_LEVELING_GRID_POINTS' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.

This was corrected in the last posting I made (March 31). Also I'm using Arduino 1.6.8. to compile.

Interesting. From 1.6.6 to 1.6.8 it works. Cool.
Oh BTW, when mine stalled, I realize it wasn't anything to do with the USB is had everything to do with the stupid cheap power port. It seems that the green connector that they used is only rated for 10A and I'm using a heated bed along with motors it melted the side and caused power issues. I solder directly to the PCB going to run another test.

Here's another tip if you are running a single fan:

Connect the fan to green connector labeled 'FAN' instead of the 12V white jumper connection

Change the Marlin firmware in pins.h

#if MOTHERBOARD == 33 || MOTHERBOARD == 35 || MOTHERBOARD == 67 || MOTHERBOARD == 68
#define FAN_PIN 9 // (Sprinter config)

to

#if MOTHERBOARD == 33 || MOTHERBOARD == 35 || MOTHERBOARD == 67 || MOTHERBOARD == 68
#define FAN_PIN -1 // (was 9 Sprinter config) FLsun disabled in order to set Auto Fan

And change in configuration_adv.h

#define EXTRUDER_0_AUTO_FAN_PIN -1

to

#define EXTRUDER_0_AUTO_FAN_PIN 9 // was -1

Now the fan turns on/off automatically at full speed when the extruder reaches the set temperature (default at 50°)

Here’s my latest FLSUN firmware update (it is a work in progress):

Besides the already existing end-stop command:

M666 X (end-stop) Y(end-stop) Z(end-stop)

- New command to set the geometry without having to recompile:

M665 H(z-Height) R(delta Radius) D(Diagonal rod)

- The same thing but with relative adjustments instead of absolute values:

M664 H(z-Height adjustment) R(delta Radius adjustment) D(Diagonal rod adjustment)

- A new command to change the segments per second without recompiling

M663 S(Segments per seconds)

- You can store all these setting in EEPROM with M500, reload with M501, reset to defaults with M502 and print with M503 as usual

- I Disabled the M206 additional homing offset: it uses Cartesian coordinates so only the Z-value is useful with deltas – I renamed that to z-Height adjustment in M664; X- and Y values of M206 are the Cartesian XY-offset of the nozzle to the true centre of the top-frame; I leave them unused, they do weird things to the calibration and bed leveling.

- Improved and faster auto calibration using a convergence matrix, probes 10 points now, calibrates end-stops, z-height, delta radius and/or diagonal rod. It calibrates to the maximum accuracy that can be achieved with the measured bed wobble.

G33 A(Auto-calibrate) R(calibrate delta Radius) D(calibrate Diagonal rod)

Default is to calibrate both delta radius and diagonal rod without changing the angles to the effector.

Run the command without A and it probes the bed once, checks and prints the calibration settings without changing them:

00:07:04.106 : center:0.02 x-tower:0.00 y-tower:-0.08 z-tower:-0.06
00:07:04.106 : . oppos-x:0.10 oppos-y:0.06 oppos-z:0.06
00:07:04.106 : std dev: 0.06
00:07:04.122 : delta geometry settings: delta radius: 104.92
00:07:04.122 : z-height: 271.06 diagonal rod: 218.15
00:07:04.122 : end-stops: x:0.00 y:-0.05 z:-0.10
00:07:04.122 : calibration OK - to save these settings use M500

- Big clean-up in main.h for deltas only: got rid of a lot of confusing code, replaced some bizarre flsun-code with more accurate and real Marlin code to make the bed leveling work better; bed leveling gave me non consistent result, I did find the little snake in the grass and corrected it. I also added an average and standard deviation to the G29 bed leveling printout,… (this version of main.h will no longer work on Cartesian printers, but it will make it easier to incorporate these changes into Marlin v1.1)

- Added homing of the axis (G28) before and after the G29 and G33 commands.

- In configuration.h:

New definition of delta z-height in the printer settings section of configuration.h (so everything is in one place and you do no longer have to look where MANUAL_Z_HOME is)

#define DELTA_HEIGHT 270 //mm

- Reconfigured pins.h so the green fan connector on the motherboard triggers the fan full speed at 45°C.

That’s all folks (for now…)

Edited 1 time(s). Last edit at 04/11/2016 12:46PM by LVD.

Why have you added a new M663 gcode, when M665 already has an S parameter defined to set the segments/second? See [reprap.org].

---

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

I know. But in my opinion 'calibrating' the processor with how many segments per second it can process before it overloads has nothing to do with calibrating the geometry of a delta so I did split them into two commands. It feels like having the settings of the nozzle temperature while printing and the settings of the PID parameters into one command. That also makes the two commands M665 with absolute values and M664 with adjustments taking the same parameters.

But maybe having 3 (4 including M666) commands for deltas is somewhat overkill, m665 and m664 are doing the same thing just in another form (absolute values / relative change), so maybe it is best to put everything in one M665 command and forget about the adjustments. I guess this originates from the math behind it, it is more universal to any delta when working with adjustments then with absolute values, so M664 was/is very useful for me being in programming mode, M665 is useful for anyone being in user mode. I will get rid of M664 in the final version.

It is an easy change (delete the 6 lines of code in M664 and move 2 other lines of code from M663 to M665). I'm gonna leave it for now, I'm having mixed thoughts for the final version M666 endstops, M665 other delta geometry, M664 other delta stuff or M666 endstops, M665 like a Swiss knife with all other delta stuff???

Here's some candidates I consider to include as well in the firmware:

Include M320, M321 and M322 commands: activate, desactivate, reset autolevel matrix

and new M323 set probing parameters N=set number of points in the probing matrix, B=set safe probe radius, absolute or percentage of the print radius ??? Z (additional probe Z_offset) that would have the same function as Z-offset in Slic3r ...those would be used in G29, G30, G33,...

Any thoughts or comments?

PS: note to myself; todo: remove the coordinates of the probing points for calibration from configuration.h and set them as fixed in G33, the maths depend on them so the user is not allowed to change them, he's only allowed to change the safe probing radius.

Hello, I just bought the FLSUN and want to add a cooling fan, I have connected it next to the hotend where it is marked fan but i doenst work, do I have to change something in the firmware?
/Joar

Edited 1 time(s). Last edit at 04/14/2016 03:22AM by Joar107.

That connector is pin 9, and is controlled by the printing software. Did you turn the fan on in Repetier or Pronterface?

Here's another thought on calibration.

I did find that solving the leaning tower problem by probing the z-height often leads to erroneous iterations that are way off reality. It can't be right that in order to solve the problem mathematically I need to adjust the measured diagonal rod or delta radius by 5mm or more. I do need reading glasses to see things up close, but I'm still capable of measuring with a precision of 0.5mm just using a ruler.

As far as I understand, the tower angle corrections are to compensate for the delta radius not being exactly the same when measured to the 3 towers. But trying to calculate that horizontal error under a very steep angle (tower corrections being only a fraction of a degree) any error on the z-probe due to the bed not having the perfect flatness and being somewhat wobbly is multiplied with the height of the tower, leading to big errors in the leaning tower problem. And since in a delta printer everything is linked, those errors propagate to end-stops and delta radius as well.

So here's another hands-on approach: do a horizontal measurement physically using a calipers in order to get the delta radius to the 3 towers by hand, do a little calc on how much X and Y offset is needed to the nozzle in order to make the 3 delta radius's being equal, set those as the additional X and Y Cartesian homing-offsets (M206 Xxx Yxx) run a couple of 4-point iterations for the end-stops and delta radius and done. And in this case small errors in the measured distances are divided by the height of the tower, so they can be measured with decent precision even using a simple ruler.

I'm playing now with a G33 in the form

G33 A(autocalibrate) X (delta radius) Y(delta radius) Z(delta radius).

First I calibrate the printer without worrying about tower angles (normal G33 A), when the iterations are done, I put the nozzle on the bed at (0,0,0) and I measure the distance of the nozzle to the frame of each tower (you do not even have to worry about effector and carriage offets). Then I correct for it by re-running the calibration and entering those measured values (G33 A Xxxx Yyyy Zzzz).

I had to iterate trough the process twice to end up with a delta radius that is equal to the three towers. The first results are looking promising. All calculated parameters (diagonal rod, delta radius, z-height, and the carriages being at equal distance from the bed when homed) correspond to what I physically measure on the printer. And that is a first in my short life of 3D-printing.

In the mean time M320 to M323 are implemented as well in the firmware. Before I release it I’m going to run some tests to see if probing a lot more points to include in the calculations improves on the precision, and maybe include an option to choose between a quick 7-point probe and a more slow N*7-point probe, probing on different radius’s.

Edited 1 time(s). Last edit at 04/15/2016 06:22AM by LVD.

I use simplify 3D and I have turned on the fan in the software and the fan is also on 255 when I check on the lcd display, I will check with pronterface tonight
Thanks/Joar

Tower angle corrections are not intended to correct to for different rod lengths. They are intended to correct for the towers not being quite equidistant from each other.

You should not allow a calibration procedure to adjust the diagonal rod length unless you include probe points that are well outside the triangular frame. Otherwise there isn't enough information to determine the rod length error.

---

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

My mistake , I ment delta radius in the previous post (I edited it).

In that case the towers not being perfectly equidistant from each other is the same problem as the towers not being perfectly equidistant from the centre, right?

Quote
LVD
In that case the towers not being perfectly equidistant from each other is the same problem as the towers not being perfectly equidistant from the centre, right?

That depends on how you define the centre. I define it as the point that is equidistant from all three towers

---

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

Linguistic calibration

I just found this thread. Hopefully when I get off work I can try some of the links. I'm haven't been successful flashing the board.

I really appreciate these modification to the calibration and levelling.... just a couple of questions and observations...
Firstly, did the temperature sensing change between this and the stock FLSUN supplied firmware? I had my repetier dialed in to perfect print with 205 for first layer and 195c for the rest. I uploaded this firmware and my prints came out perfectly formed but almost no adhesion between the layers so it looks good but has the strength of ice cream wafer.. (not the posh italian ones, but the cheap lidl ones!!)
I just tried upping the temperature and seems it is much better again also noticed much more variation on the reported temperature... it used to be fairly static once it reached max temperature... So it my temp sensor now more in-/accurate/regularly read?

Are the results of the auto-levelling stored? do I have to repeat each time I switch on reset? I did have G29 in my start up gcodes before each print but now that takes much longer and I wonder if it is necessary?

Lastly ( for now ) and mostly stupid request, put can you make the autolevelling a little more melodic? I got to like what sounded like a bad rendition of Nirvana's "Come as you are" at the start of each print as the head was moved to the 9 sample positions in the original firmware.. I'm not suggesting beethoven to be frank, your auto-levelling routine sounds like scratching nails down a blackboard please fix this as your highes priority..

Edited 1 time(s). Last edit at 04/17/2016 06:37AM by deltamelter.

actually, the print just finished and the results are pretty much the same except for the bottom 5-6 layers which bonded a little better...
Was extrusion rate changed at all in this firmware, compared to FLSUN original?
Otherwise, I will check I don't have a blockage or perhaps switch back to the original fw to compare this piece...

oh, and was I supposed to reset the eeprom between these versions too? I thought that this was essentially the same base as original flsun so didn't do that...

Quote
deltamelter
oh, and was I supposed to reset the eeprom between these versions too? I thought that this was essentially the same base as original flsun so didn't do that...

Ok, so I went back to the original firmware and did g29 and the nirvana tune was back but probing near the top instead of down at the base... reset eeprom like I should probably have done with LVD firmware..

""PS: after installing the firmware the first time do reset the EEPROM with M502 and M500""

Currently printing the same piece and it is coming out completely solid... so I will perhaps try again with LVD firmware and eeprom reset...

Nope, definitely under-extruding compared to stock FLSUN firmware even after resetting the eeprom.
I will go back to the original firmware and print the rest of the items but would like to find the reason for this massive difference in the resulting output...
I would hope this is just some minor tweaking and will look to this again, but I wasted enough plastic on inedible wafers for now...

Thank you LVD for your work I tried one of your firmware, it worked for me. The only problem is the pla stucking in the bowden tube
Itried the flsun PLA, and a better one, but it alwas stuck in the tube. I think i'll have to order a other one.


When i'll get the new PTFE tube I'll try your last firmeware.

Edited 1 time(s). Last edit at 04/17/2016 06:04PM by schwartzf.

I upgraded to an all metal extruder so I had to change the E-steps from the original. Reset it to 150

#define DEFAULT_AXIS_STEPS_PER_UNIT {XYZ_STEPS, XYZ_STEPS, XYZ_STEPS,150}

in configuration.h to solve the underextruding problem.



To restore the original temperatures uncomment

#define PIDTEMP

Quote
LVD
I upgraded to an all metal extruder so I had to change the E-steps from the original. Reset it to 150

#define DEFAULT_AXIS_STEPS_PER_UNIT {XYZ_STEPS, XYZ_STEPS, XYZ_STEPS,150}

in configuration.h to solve the underextruding problem.



To restore the original temperatures uncomment

#define PIDTEMP

Thanks LVD!!

It is probably just the extrusion rate that caused the print problems, I will test it out and report back.
What are the changes regarding PIDTEMP? Actually having looked around, I will rephrase that to what led you to choose bang-bang over PID in this case?

Also, is the auto-levelling result stored? how often would it need to run, just after replacing the bed or after every power cycle / startup?


Thanks

Edited 1 time(s). Last edit at 04/18/2016 11:27AM by deltamelter.

I was just testing the difference between PID and bang bang

The autolevel results are not stored

How set up the heated bed in Configuration.h ?

I ordered and received:
* PCB Heatbed MK2Y 200
* MKS HOTBed MOS V0.1
* Temp sensor

The temp sensor is not responding in Repetier, and its not possible to switch the heater on.

And how did you mount the heatbed to the Delta Printer ?
The heat bed plate is not really flat by itself.
But I guess that when the glass plate is clamped on top of the heatbed it will not be an issue.

Edited 1 time(s). Last edit at 04/18/2016 04:22PM by JanR.