›

Unexpected tool change in version 1.04

lmcbmailmcbmai
in Repetier-Firmware
Hi,
I have IDEX printer that still runs 1.04 version of firmware. I know, I need to upgrade it, but it is my only working printer at the moment and I don't want to mess up with it :)

For quite some time I was not using IDEX functionality and had 2nd extruder disabled in the firmware, but recently I began to work on a project that requires many identical printed parts and to save time I reflushed firmware and enabled 2nd extruder and ditto mode.

Everything works fine and I can print 2 identical pieces at the same time. However, I started having occasional failures when printing with only one (left) extruder. All the sudden printer switches to right extruder as if T1 command was sent and that ruins the print because the second extruder is not heated. Tonight I got "lucky" - the failure happened at the very beginning of the print and the entire part was printed with right extruder. The problem however is - that extruder was loaded with a filament of "wrong" color. The same gcode file executed 2 more times after that run correctly and the parts were printed with left extruder, as they should.

My starting code in Cura for single extruder prints contains M280 S0 in the very 1st line to make sure ditto mode is disabled and my understanding is unless T1 command is sent, the right extruder should remain idle.The only reason of such failures that I can think of is communication errors between Octoprint and the mainboard, but they are extremely rear and the chance that certain command will be understood as T1 is even smaller.

So the reason of this post is to ask if anyone has experienced this and what was your solution/workaround.

Thanks

Comments

  • RepetierRepetier
    One extruder prints often have no extruder selection and with ditto mode off you use the currently active extruder. Could it be that somehow T1 was activated before you started the print? One solution might also to always send T0 in start gcode for single extruder prints. Especially after M280 S0. If ditto was already off I think it will not change extruder explicitly to T0.
  • lmcbmailmcbmai
    I do have T0 in the startup script right after M280 S0 and because failure can happen at any time during the print, I don't think that is an issue. I wish there would be a setting in EEPROM called "Disable T1 command" - Yes/No (1/0) option.  I understands that 1.04 is not developed anymore, but I may try to find the time and try to implement it myself. If that works it will eliminate at least corrupt code processing possibility.
  • RepetierRepetier
    In this case it must in deed have received a T1. Problem is that T1 is really a short command and if G1 gets T1 the rest is irrelevant, also checksum should normally prevent this.

    If you enable echo (M111 S7) firmware will write back received commands. Together with logging it should be possible to track how exactly it happens if you know the time or just search for T1 in log. Then it is also sure a command send is the reason and not some internal thing changing extruder id. Not that I have heard about that happening regardless of old firmware or not.
  • lmcbmailmcbmai
    Thanks for your suggestion. I never used M111. Looks like the perfect fit for this troubleshooting. Enabled serial log in Octoprint and added M111 to my startup scripts. Will wait until the next failure happens and then update this thread.

  • lmcbmailmcbmai
    Caught it!!

    Recv: ok 2452
    Send: N2453 G1 F900 X193.37 Y132.276 E696.58483*58
    Recv: Echo:N2452 G0  X196.51 Y135.42 F3000.00
    Recv: ok 2453
    Send: N2454 G0 F3000 X193.342 Y131.4*115
    [...]
    Recv: Echo:N2453 G1  X193.37 Y132.28 E696.5848 F900.00
    Recv: ok 2454
    Send: N2455 G1 F900 X196.545 Y134.603 E697.10687*2
    Recv: Echo:N2454 G0  X193.34 Y131.40 F3000.00
    [...]
    Recv: SelectExtruder:1
    [...]
    Recv: Error:Wrong checksum   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    [...]
    Recv: FlowMultiply:100
    Recv: Echo:T1  B0.00  <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    Recv: ok 2455
    Send: N2456 G0 F3000 X196.578 Y133.787*117
    Recv: Echo:N2455 G1  X196.55 Y134.60 E697.1069 F900.00
    Recv: ok 2456
    Now the question is how to stop it from happening?
  • lmcbmailmcbmai
    Have too many things to print and too little time to troubleshoot further and/or experiment. Decided to go with low tech solution - will use 2 SD cards with firmware one for single head printing another for Ditto mode.

    Thanks again for your help.
  • RepetierRepetier
    What was in the ... when it happened? Just where it is interesting you reduced the log?
    I wonder what is happening there as I see so far no T1 or B0. Might be interpreted as binary command but without correct checksum which is required in binary format as I think it should not execute it. Will check later the fimrware source regarding checksum test in binary format.
  • lmcbmailmcbmai
    Sorry, I did not realize you will need to see something more than the actual error. Unfortunately after capturing this I disabled Octoprint serial log and since then it overwrote that log file. I was not able to find Gcode file either. Most likely I sliced a new revision of the same part and saved it with the same name. But that's OK. At least we know that it is communication error.

    Thanks
  • RepetierRepetier
    Yes, communication error is in deed the root problem.
Sign In or Register to comment.