fairly recently upgraded to marlin 2.0(bf) on my scratch built delta printer, had some problems with calibration but eventually got it running and was making some decent prints. I was looking forward to using some of the new features like linear advance, but then the printer started acting in a manor that I can only describe as "goofy". It started with skipping steps & jamming my extruder, something that had not happened since I addressed those problems in the early days (~3 years ago). I had been mulling over reworking some of the hotend, and that was the last straw.
So I built a new heater block, featuring 2 cartridge heaters (5ohm) in parallel for an effective 2.5ohm heater. I am sure some will say that's a bad idea, but the mosfet it well cooled and seems to handle it just fine. Expecting a powerful heater, I was surprised to still have the same weird extruder behavior and started to get thermal warnings. Honestly, they seem completely erroneous, but I am not 100% sure of the rules for triggering. The settings I know about define a watch period and temp rise (currently 40s, 2deg), that rule has not been broken, yet the halting alarm still goes off. This is especially prone to happening when setting my z height via a g33 p1 command. Probe is set to be done with the heater & fan off and I have 580mm of z travel, so by the time it turns back on, its down about 8-10 degrees at which point it usually screams at me. So what thermal protection rule might I be triggering? and where can I find that in the code?
Then in the 11th hour last night, the machine started acting like it had a stroke. Processing some commands perfectly fine, others a little off and some completely out of wack. Some examples: I have a tramming routine that does an m48 (x4) at each of my adjustment screws:
m48 p4 v2 x0 y0; ctr
m48 p4 v2 x-130 y-75; x
m48 p4 v2 x130 y-75; y
m48 p4 v2 x0 y150; z
this comes into the first point, does no probing, slides across to the next 3 points without probing or lifting & buries the nozzle in the table at several points.
when manually controlling the machines position, it allowed be to blast right by my end stops at the top.
Homing seems to work just fine every time, but if I go from home (0,0,580) to say (0,0,25), I end up around (+50, +25, 5). In other words, when viewed from the x tower it thinks the center is away from the x tower & to the left. The z height is also too low. All the motors seem to run fine during other operations. All the motors are running, all the drivers are working, belts are properly tensioned, no loose pulley set screws, ect....
I have tried recompiling, different compilers even nothing seems to change that
At this point, I was fed up with marlin2.0, and before I upgraded I set aside a pre-compiled version of 1.1.9 that I know worked. Yet I have the same sort of behavior. I should note that I have no troubled uploading new firmware. So the problem has got to be in whatever is left, that's possibly faulty hardware and EEPROM. Having spent days reworking some potentially sketchy connections and seeing no improvement, I am beginning to think the problem might be in the arduino / ramps board. So I enabled m100, not real sure how to use it, but here is what I got from m100 f:
21:02:02.854 : bss_end : 0x142A
21:02:02.854 : free_memory_start : 0x142A
21:02:02.854 : free_memory_end : 0x21D6
21:02:02.854 : Stack Pointer : 0x21D6
21:02:02.854 : Found 3224 bytes free at 0x1432
21:02:02.870 : M100 F
21:02:02.870 : fmc() n=3500
21:02:02.870 : free_memory_start=0x142A end_free_memory=0x21D6
21:02:02.870 : (1) found=3224
21:02:02.870 : block_found=1 return=0
21:02:02.870 : check_for_free_memory_corruption() = 0
from what I know, that seems fine.
As a last ditch effort, I am going to swap out the power supply tonight, I have some minor concerns about it. chiefly that without usb power, I cannot read the LCD screen. Its backlit, but no visible text. Perhaps this indicates a low 5v (vcc) line, which I could see causing some of this spooky behavior. Though spooky might be the wrong work, it is consistent, just consistently wrong. I kinda doubt this will fix anything as this behavior was happening while the printer was still working.
--> did this last night, made no difference at all.
Anyone who sees a problem, or needs me to run further diagnostics please speak up!
Lastly, before this I had been considering an upgrade to a 32bit system, that's probably in my very near future now. So I am looking for suggestions on a new brain & step drivers. I am wide open on boards, but I think I want to run TMC2209 drivers...but the right words could persuade me otherwise.
If you read all of this, or even most, thank you, sorry its so long, but I have been through an epic saga with thing.
So I built a new heater block, featuring 2 cartridge heaters (5ohm) in parallel for an effective 2.5ohm heater. I am sure some will say that's a bad idea, but the mosfet it well cooled and seems to handle it just fine. Expecting a powerful heater, I was surprised to still have the same weird extruder behavior and started to get thermal warnings. Honestly, they seem completely erroneous, but I am not 100% sure of the rules for triggering. The settings I know about define a watch period and temp rise (currently 40s, 2deg), that rule has not been broken, yet the halting alarm still goes off. This is especially prone to happening when setting my z height via a g33 p1 command. Probe is set to be done with the heater & fan off and I have 580mm of z travel, so by the time it turns back on, its down about 8-10 degrees at which point it usually screams at me. So what thermal protection rule might I be triggering? and where can I find that in the code?
Then in the 11th hour last night, the machine started acting like it had a stroke. Processing some commands perfectly fine, others a little off and some completely out of wack. Some examples: I have a tramming routine that does an m48 (x4) at each of my adjustment screws:
m48 p4 v2 x0 y0; ctr
m48 p4 v2 x-130 y-75; x
m48 p4 v2 x130 y-75; y
m48 p4 v2 x0 y150; z
this comes into the first point, does no probing, slides across to the next 3 points without probing or lifting & buries the nozzle in the table at several points.
when manually controlling the machines position, it allowed be to blast right by my end stops at the top.
Homing seems to work just fine every time, but if I go from home (0,0,580) to say (0,0,25), I end up around (+50, +25, 5). In other words, when viewed from the x tower it thinks the center is away from the x tower & to the left. The z height is also too low. All the motors seem to run fine during other operations. All the motors are running, all the drivers are working, belts are properly tensioned, no loose pulley set screws, ect....
I have tried recompiling, different compilers even nothing seems to change that
At this point, I was fed up with marlin2.0, and before I upgraded I set aside a pre-compiled version of 1.1.9 that I know worked. Yet I have the same sort of behavior. I should note that I have no troubled uploading new firmware. So the problem has got to be in whatever is left, that's possibly faulty hardware and EEPROM. Having spent days reworking some potentially sketchy connections and seeing no improvement, I am beginning to think the problem might be in the arduino / ramps board. So I enabled m100, not real sure how to use it, but here is what I got from m100 f:
21:02:02.854 : bss_end : 0x142A
21:02:02.854 : free_memory_start : 0x142A
21:02:02.854 : free_memory_end : 0x21D6
21:02:02.854 : Stack Pointer : 0x21D6
21:02:02.854 : Found 3224 bytes free at 0x1432
21:02:02.870 : M100 F
21:02:02.870 : fmc() n=3500
21:02:02.870 : free_memory_start=0x142A end_free_memory=0x21D6
21:02:02.870 : (1) found=3224
21:02:02.870 : block_found=1 return=0
21:02:02.870 : check_for_free_memory_corruption() = 0
from what I know, that seems fine.
As a last ditch effort, I am going to swap out the power supply tonight, I have some minor concerns about it. chiefly that without usb power, I cannot read the LCD screen. Its backlit, but no visible text. Perhaps this indicates a low 5v (vcc) line, which I could see causing some of this spooky behavior. Though spooky might be the wrong work, it is consistent, just consistently wrong. I kinda doubt this will fix anything as this behavior was happening while the printer was still working.
--> did this last night, made no difference at all.
Anyone who sees a problem, or needs me to run further diagnostics please speak up!
Lastly, before this I had been considering an upgrade to a 32bit system, that's probably in my very near future now. So I am looking for suggestions on a new brain & step drivers. I am wide open on boards, but I think I want to run TMC2209 drivers...but the right words could persuade me otherwise.
If you read all of this, or even most, thank you, sorry its so long, but I have been through an epic saga with thing.