Welcome! Log In Create A New Profile

Advanced

discontinous printing

Posted by fantom 
Forum List Message List New Topic
fantom
discontinous printing
October 21, 2012 08:58AM
Having edited the firmware (see Z-axis out of scale) the printing is discontinous in the periphery as if the printer is waiting for something. When printing one-layer thin objects it goes continous and make fine prints, but when printing more complex objects such as the gnome the speed goes down and it is discontinous. Attached please find a picture of part of 2 gnomes. The small is printed with the original TZ firmware and the big one with the 18 feb 2011 firmware, modified.
Reply Quote
Attachments:
open | download - gnome.jpg (523.2 KB)
DeuxVis
Re: discontinous printing
October 21, 2012 02:38PM
That's really too bad we don't have access to that new firmware sources sad smiley

Have you modified the communication speed ? It might be possible the board is waiting for more gcode lines here, due to so many little moves - compared to straight big lines in simple geometry objects. I use 115200 with repsnapper.

Apart from that, maybe playing with buffer sizes in the firmware could help, never tried that myself.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 21, 2012 04:48PM
In the firmware code intercom.h I found this:

// Communication speed

//#define RS485_BAUD 115200
#define RS485_BAUD 1000000

// The acknowledge, start, end, error and checksum characters

Should that be changed also or is it something else?
Reply Quote
DeuxVis
Re: discontinous printing
October 22, 2012 03:26AM
Mmm, I don't think so, it's probably about the internal communications between the heater control board and the main board.

I didn't change it.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 22, 2012 06:38AM
Where could the buffer size be defined, I have not found it.
Reply Quote
DeuxVis
Re: discontinous printing
October 22, 2012 06:56AM
in configuration.h :

// The size of the movement buffer
#define BUFFER_SIZE 4 // *RO

Note : You can decrease it, but I doubt it would do any good.
If you want to increase it, which makes more sense, looks like you have some initialisation code to change.

For instance if you switch it to 8, you have to add this in FiveD_GCode_Interpreter.pde (new code in bold) :

static cartesian_dda cdda0;
static cartesian_dda cdda1;
static cartesian_dda cdda2;
static cartesian_dda cdda3;
static cartesian_dda cdda4;
static cartesian_dda cdda5;
static cartesian_dda cdda6;
static cartesian_dda cdda7;

and later on :

  cdda[0] = &cdda0;
  cdda[1] = &cdda1;  
  cdda[2] = &cdda2;  
  cdda[3] = &cdda3;
  cdda[4] = &cdda4;
  cdda[5] = &cdda5;  
  cdda[6] = &cdda6;  
  cdda[7] = &cdda7;

Absolutely untested, it might actually not do anything.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 22, 2012 02:10PM
It made no difference setting it to 8.....it stops 2 - 3 times pr. sec.
I was looking for another buffer, but perhaps this is the one to handle the communication with the host?
Reply Quote
DeuxVis
Re: discontinous printing
October 23, 2012 04:55AM
Not a communication buffer per se, but a commands received buffer.

Well I'm pretty out of ideas there, next thing would be to add profiling informations to debug output to see what is happening. Can you handle that ?

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 24, 2012 12:48AM
No.....
could Sprinter firmware do?
Reply Quote
DeuxVis
Re: discontinous printing
October 24, 2012 02:26AM
The main thing that doesn't allow to switch easily to another firmware is the communication with the heat monitoring daughter board. If you can replace it with a heating resistor plugged in the fan terminal and a thermistor hooked to one of the free extension pins, you're good to change to sprinter or any [rd]ecent firmware.

There's a wiki page talking about that upgrade, but it's for the old version of Monotronics, so you'll be on your own to find which pins you can use.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 25, 2012 02:21PM
Now I have got the code for Monotronics v.2.1 I Will test it when I come home (monday).
Reply Quote
DeuxVis
Re: discontinous printing
October 26, 2012 02:45AM
Great ! Don't forget to make it public so that other people with the same problem have a fix available.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
October 26, 2012 08:25AM
This is what I got
Reply Quote
Attachments:
open | download - Monotronics FW2.zip (284.4 KB)
fantom
Re: discontinous printing
October 29, 2012 02:59PM
I can't see the difference, but it must be somewhere, at least after making all the same modifications + one more in configurations.h :

//#define ACCELERATION_ON

it prints much more continous.
I am a little frustrated not to know exactly what makes the difference, but it works.
Reply Quote
DeuxVis
Re: discontinous printing
October 30, 2012 09:44AM
Yes, not much changed actually.

The steps_per_mm are upgraded to different default values (probably due to the new motor drivers using different micro stepping ? Notice the x8 ratio, I believe they switched to x16 microstepping - it's x2 on the old board) :

diff -ur V1/FiveD_GCode/FiveD_GCode_Interpreter/configuration.h V2/FiveD_GCode/FiveD_GCode_Interpreter/configuration.h
--- V1/FiveD_GCode/FiveD_GCode_Interpreter/configuration.h	2011-01-16 06:21:20.000000000 +0100
+++ V2/FiveD_GCode/FiveD_GCode_Interpreter/configuration.h	2011-10-14 21:53:41.000000000 +0200
@@ -188,15 +188,15 @@
 
 // Axis scaling in stepper-motor steps per mm of movement
 
-#define X_STEPS_PER_MM   10.047
+#define X_STEPS_PER_MM   80.376
 #define X_STEPS_PER_INCH (X_STEPS_PER_MM*INCHES_TO_MM) // *RO
 #define INVERT_X_DIR 0
 
-#define Y_STEPS_PER_MM   10.047
+#define Y_STEPS_PER_MM   80.376
 #define Y_STEPS_PER_INCH (Y_STEPS_PER_MM*INCHES_TO_MM) // *RO
 #define INVERT_Y_DIR 0
 
-#define Z_STEPS_PER_MM   805.030
+#define Z_STEPS_PER_MM   6440.24
 #define Z_STEPS_PER_INCH (Z_STEPS_PER_MM*INCHES_TO_MM) // *RO
 #define INVERT_Z_DIR 0
 
@@ -206,7 +206,7 @@
 // E1 for extruder 1, and so on.
 
 //#define E_STEPS_PER_MM   0.9      // NEMA 17 extruder 5mm diameter drive - empirically adjusted
-#define E0_STEPS_PER_MM   3.5      // NEMA 17 59/11 geared extruder 8mm diameter drive
+#define E0_STEPS_PER_MM   28      // NEMA 17 59/11 geared extruder 8mm diameter drive
 #define E1_STEPS_PER_MM   17.6      // NEMA 17 59/11 geared extruder 8mm diameter drive
 
 // The temperature routines get called each time the main loop

The output of the temperatures and coordinates reported on demand to host are tweaked a bit (probably for better compatibility with host softwares) ?

diff -ur V1/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde V2/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde
--- V1/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde	2011-02-16 05:58:38.000000000 +0100
+++ V2/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde	2011-07-16 02:26:15.000000000 +0200
@@ -575,13 +575,13 @@
 
 			//custom code for returning current coordinates
 			case 114:
-				Serial.print("C: X");
+				Serial.print("C: X:");
                                 Serial.print(where_i_am.x);
-                                Serial.print(" Y");
+                                Serial.print(" Y:");
                                 Serial.print(where_i_am.y);
-                                Serial.print(" Z");
+                                Serial.print(" Z:");
                                 Serial.print(where_i_am.z);
-                                Serial.print(" E");
+                                Serial.print(" E:");
                                 Serial.println(where_i_am.e);
 				break;
 
diff -ur V1/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde~ V2/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde~
--- V1/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde~	2011-02-16 05:58:37.000000000 +0100
+++ V2/FiveD_GCode/FiveD_GCode_Interpreter/process_g_code.pde~	2011-07-16 02:26:15.000000000 +0200
@@ -509,6 +509,8 @@
 
 			//custom code for temperature reading
 			case 105:
+				Serial.print("T:");
+				Serial.println(ex[extruder_in_use]->getTemperature());
 				Serial.print("ok T:");
 				Serial.print(ex[extruder_in_use]->getTemperature());
                                 Serial.print(" B:");

And I believe that's all.


There are other changes regarding temperature management in the applet subdir, which seems to be older, but I have no idea what the code in that folder is used for (most of it is a duplicate).

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
November 15, 2012 08:07AM
There is a marked difference in the size of the problem when I change from RepSnapper to Pronterface. Pronterface works best, but still, when I am making small cirkles the printing is discontinous. Is there a program with no garbage / features, a program that just sends the code as if it was located on a stick?
Reply Quote
DeuxVis
Re: discontinous printing
November 15, 2012 10:32AM
Yes there is a script which is a part of the pronterface/printrun suite that does that : "pronsole.py is an interactive command-line host software with tabcompletion goodness".

There is also something called "send.py" there : [reprap.org] which is supposed to be the most simple gcode sender.

I have never tested those then, so good luck winking smiley


Edit I just realised that send.py is a part of skeinforge, which maybe is not obvious to you just by reading the wiki page I linked.

Edited 1 time(s). Last edit at 11/15/2012 10:38AM by DeuxVis.

Most of my technical comments should be correct, but is THIS one ?
Anyway, as a rule of thumb, always double check what people write.
Reply Quote
fantom
Re: discontinous printing
November 15, 2012 02:59PM
Thanks,
send-gcode.exe solves completely the problem with the discontinous printing.
I just have to remove 2 lines:
;M109 s250;.... and
M82 ; use absolute distances for extrusion

edit:
only M82 has to be removed

Edited 1 time(s). Last edit at 11/16/2012 01:57AM by fantom.
Reply Quote
fantom
Re: discontinous printing
November 20, 2012 04:53PM
"send-gcode.exe" has no error handling and is no solution, but identifies the problem as Win7 being to slow for the purpose. The processor is an Atom 1.60 GHzx2 with 2GB RAM. Perhaps a faster PC could do.
Now the same PC is set up with Ubuntu and with Ubuntu running Pronterface there is no problem with the speed. (but a hell of other problems with authorizations).
Reply Quote
Newer Topic Older Topic
Sorry, only registered users may post in this forum.

Click here to login