Having trouble with new printer using v 1.04 and Repetier Host. OK w/ factory Marlin using R. Host

Doug40

I assembled a I3 clone for a friend. It is identical to mine, except with a single extruder. A USB print worked with R. Host and the original Marlin FW. I installed Repetier FW 1.04 and I can't seem to get it to start a print using USB. R. Host gives several file error messages and the job kills before it does anything. One thing notable is that when the print is started, the Z axis raises 10 or 20 mm and then stops. Everything seems to be OK with manual control and running from an SD card. I'm about ready to back up to 0.92 unless this symptom is familiar to anyone.

Repetier

That is too vague. Can you post a log with all lines when the problem happens so I can see what is happening. I have no problems with 1.0.4 so I guess it is either config or bad values in eeprom.

Doug40

You have answered my main question, and that is that there aren't any other similar reports. I think I'll just load the FW I have been using on my printer. It is from April 2018, and the only difference in the printers is that mine has two extruder steppers and a shared hotend. The control board is a later version of the same design, but it I haven't seen anything to make me think that's significant.

Thanks for all. I may be back if I can't sort it out.

MartinH

You say it worked ok with marlin, did you erase the eeprom befor loadng Repetier firmware as sometimes you can get problems with old marlin values left in the eeprom.

Doug40

I never did anything with the EEPROM, but I checked it to verify the steps/mm and PIDs were as expected. I didn't find any way to view the EEPROM data in R Host. It's reading data item is greyed out in my version of Marlin.

After reloading and printing with the antique Marlin that the printer shipped with, I loaded Repetier V.92. It worked normally. After the failure with V1.0.4, the log file from Repetier Host ended with about 8 or more messages about a file error, maybe not found. There was no explicit data. I will follow up with some more data much later in the day.

I was hoping to send a dif file between the config.h files for V.92 and 1.04, but I don't know how to create one. The V.92 Config.h file was created by the configuration tool from the one I used with V 1.0.4. Would these files be of any help? Other than that, the only thing I know about is the log file from R. Host.

Doug40

I compared the config.h files between the one used for V.92 and V1.0.4, and the differences were as expected.

I loaded v104 two times, toggling the eeprom flag on the second try. The results were identical.

I loaded a model, sliced it and then pressed print with the printer connected, but with no manual operations.

In each case RH displayed JOB KILLED and then reset the printer. No heaters were turned on for a noticable time.

I attached the RH log files.

edit: they appeared to be attached, now they are not visible

Repetier

You can not attach files in forum. If it is not too much just paste in comment alternatively use pastebin or alternative or dropbox to show extra files.

Doug40

They are here, along with the FW I used to test.

https://1drv.ms/f/s!AoMNMLsOFAgFkdV1rUnZODCH2G9hag

I used the same model and printer setup in RH for testing in both FW versions of Repetier FW.

Repetier

The log is incomplete as it does not contain ack/M105 messages so it is hard to see what is going on. What I see is

15:53:55.150 : N18 M190 S5597

15:53:55.150 : N19 M104 S202*93

15:53:55.165 : N20 G2833

15:53:55.165 : N21 G1 Z5 F5000*55

15:53:57.212 : Printer reset detected - initializing

15:53:57.228 : start

Bed needs to go to 55°C and 2 minutes later a reset happens. Did you reset it and if so why or is that the problem you mean? After a reset host of course stops printing.
Did it just not get the temperature or did the heater cause power problems? Heated beds sometimes have less resistance then they should and use sometimes too much current.

In any case it is important to see full communication. You should even enable echo so you see which commands got executed and not only send. Then you know which command is causing the problem. As a test send same command directly from manual console and see if same thing happens.

At the first connect in log you see
Info:External Reset
that is ok as host resets printer on connect. After the further start I do not see a reason which I'd expect.

Doug40

I repeated the test. The new log file is in the same link.

The log files i made and saved were different than ones I had seen earlier, and I found that I had switched printers somewhere along the way and that resulted in a difference in the log file.

The file I added used the corredt printer in RH. I preheated the bed and extruder before loading and slicing the model.

When I press print, the message that something was heating was on the printer display for a few seconds, and then RH reported job killed, and the printer Z axis drove up about 10-15 mm.

I repeated the test after using a different slicer and a different printer setting profile, with the same results.

Doug40

I created a config.h file for the FW I am using on my printer, dtd April 17 2017 from the config.h I created for the V1.0.4 build and compiled it with the 04/17/17 pkg. I used notepad++ to compare the files and make changes to the config.h that I used on my printer. When uploaded, it printed a model normally on the printer. So, it looks to me like that means there is an incompatibility in the config.h or something else in the V.1.0.4 files I downloaded. The config.h file for V104 is in the folder I sent the link for.

Repetier

You still need to isolate the command causing the problem. In the log again

05:51:04.563 : N14 M530 S1 L1558

05:51:04.563 : N15 M531 Tag New Rnd Ben*15

05:51:04.563 : N16 M117 ETE 24m 59s115

05:51:04.563 : N17 M532 X0 L0*5

05:51:04.579 : N18 M10728

05:51:04.579 : N19 M190 S55*96

05:51:04.579 : N20 M104 S20287

05:51:04.594 : N21 G28*32

05:51:04.594 : ok 14

05:51:04.594 : N22 G1 Z5 F5000*52

05:51:05.438 : Printer reset detected - initalizing

05:51:05.501 : start

is the sequence before the restart. So one of the commands does cause this. So send them manually and see at what command it exactly happens. Bed was not up so it would need to stop at M190 S55 or that even causes it also heating before was good. But I see no further temperatures and M190 reports them automatically, so it could also be M107 or one of the 4 commands before. M107 would also a good guess if fan is set to wrong pin, e.g. reset pin, but pin 7 is the official fan pin as it looks.

Doug40

FWIW, there is no PWM fan on this printer. I left it in there because it will likely be added. I added the config.h file from an Apr. 2017 release to the folder with the logs. The fan definition is the same, and that FW works OK. You can compare the two files; they are almost identical except for the structural differences between the two versions.

I will run through the commands manually as suggested, later in the day.

What is the * and the number following it. I don't know what to do with it. Give me an example of the format to use.

Another option is to use Teamviewer, and you could control the computer yourself.

Doug40

I didn't have time today to try anything on the printer, but I was looking at the Slic3r profile for printers, and noticed an option I had not seen before. It refers to set-and-wait command for bed and extruders. Apparently the check box is applicable is applicable only if the firmware supports it. It has never been checked in anything I have used.

Repetier

The * part is the checksum. You need to send the part after Nxxx until the *. Nxx and *52 get added by host automatically.

Doug40

I am going to have to put this on hold for a while. One printer to fix, one to get ready to hand off to a youngster, etc.

I WILL get back to it within the next week or 2 or 3, most likely on my printer, which is a superset of the one that is having the problem with 1.0.4.

Doug40

I haven't been able to find a conflict, but I am beginning to think there is an incompatibility with the display controller. It is a LCD2004 type, but of a different design than mine from 3 years ago. When I start a print, I often see a page showing on the display that has no reason to be there. I've tried executing the commands in the gcode file, and have got past any extruder commands without any problem. There is a "error writing to file" message in the log that repeats several times when it shuts down. Otherwise, the 104 firmware seems to do everything OK manually via USB, and printing from an SD card. Another issue that got in the way was that between the Arduino SW and R Host, the com port would bounce between 4 and 5 occasionally. I don't remember seeing that before, but I don't think it affected anything.

I was able to install on the printer a release which has files dated 2/11/18 in the ZIP, and It runs everything OK, AFAIK. I am through with this printer, but will take it up again on my printer once the new printer gets in the young hands of it's new owner.

My printer has been running the same FW since 03/18. The only difference is that it has two extruders and a LCD2004 display controller of a different origin, plus a few other minor step/setting differences.

Repetier

If a display makes sense meaning it reads some understandable text it is right. Newer firmware has e.g. a process screen now.

Some boards use a different port for uploading firmware. Then they go into dfu mode and windows shows this as different port. If that is what you see it is ok.

Doug40

I tried FW104 on my printer. It's essentially identical except for having a second extruder. The results are the same, Job Killed. Log shows file error. I tried disabling the display in the FW and preventing RH from writing ETE to the display: no difference. Other than repeating what I have done with the single extruder printer, I'm out of ideas.

Everything I have tried via USB with RH manual commands or gcode commands or SD has worked normally; it's only when a print is started via USB that there's a problem, and the only recognizable error that I see is a write-to-file error. What I have seen in RH after starting the print is a status notice of Heating Extruder, immediately followed by Job Killed. The bed and extruder were up to temp when I started the print. I don't know if there was reason for the FW to wait further.

I created the config.h file with the configurator using the config file for the FW101 that I've been using for almost a year. I didn't dwell on every setting, but I didn't see anything that made me think I was missing something.

FWIW, the control board in the printer is a GT256, by Geeetech. The controller board in the FW is, and has always been type 37.

Repetier

How much free memory does firmware show on start. Should be more then 1500 byte as you are using a cartesian printer. If it is less it could cause strange errors. But that is normally only a problem of delta printers whcih need more ram.

You can also in host set sd card to not present to prevent any file related gcodes.

The error you see comes from SDCard.cpp from thsi line
Com::printFLN(Com::tErrorWritingToFile);

but that case only happens if you tell host to upload a file for printing. It gets called from commands.cpp

void Commands::commandLoop() {
//while(true) {
#ifdef DEBUG_PRINT
debugWaitLoop = 1;
#endif
if(!Printer::isBlockingReceive()) {
GCode::readFromSerial();
GCode *code = GCode::peekCurrentCommand();
//UI_SLOW; // do longer timed user interface action
UI_MEDIUM; // do check encoder
if(code) {
#if SDSUPPORT
if(sd.savetosd) {
if(!(code->hasM() && code->M == 29)) // still writing to file
sd.writeCommand(code);
else
sd.finishWrite();
#if ECHO_ON_EXECUTE
code->echoCommand();
#endif
} else

you see it gets only called id sd.savetosd is true. That should only happen if you start writing a file but in your case it happens also somehow wothout causing the file error as file is not opened.

Change

if(sd.savetosd) {

if(false & sd.savetosd) {

and it should not happen any more but you can not upload files to sd card over host then. So only a temporal fix.