Posts made by Grimsrude

So, maybe a bit unconventional for this sub-forum, but after a few days (and thinking I fried something what felt like 12 different times) I finally got my BL Touch wired up and working on my older Duet Wifi 1.0, latest FW (2.01(RTOS)) following the instructions from a combination of the DuetWiki and betrue3d's guide - some things like switching the probe type / mode from 5 to 9 though I'm unsure if that ultimately made a difference. The printer is a coreXY (TronXY X5S gutted with Titan Aero, specifically).

Anyways, I wanted to actually lay out several what seemed like odd and unrelated issues I had while getting this setup and what I think the solution(s) ended up being.

When first wiring up the BL Touch, everything seemed to be testing OK. Cut the trace so it would run on 3.3V, snipped up some extended cables, etc. Then I started testing homing instructions and got really weird erratic behavior.

An example would be the A motor run fine but any movements needing the B motor would skip steps, and randomly the Z axis would have "low steps/mm" in that it would move very fast and much farther than intended. Also during several of the tests I would get undervoltage errors and motor current errors. I fiddled around with motor connections thinking they maybe got loose, I tested my PSU (24V), tried adjusting it's voltage around, I tried probing the 3.3V and 5V rails on the duet - nothing was working, but everything looked fine.

I figured I had messed up my wiring on the BL Touch because it was the only change I made so I tried moving it to a different PWM channel. At this point, even after confirming all the gcode was updated to reflect the change, and confirming my wiring again, I was still having issues and even worse, now the BL Touch stopped responding to commands.

Thinking I must have somehow borked and fried the BL Touch completely, I pulled it, applied my backed up config files, and back to square one - everything worked again just no probe. I figured that the BL Touch was just too much hassle for the Duet and actually threw the thing in my bin. I noticed I had a inductive sensor laying around and wired that up - got a couple prints out of it before needing to swap to a glass bed.

Long story short, I got annoyed with the inductive sensors restrictions on build surfaces and went back to the BL Touch in the trash. I decided, before all else, to see if it even works at all. I used a razer blade and cute the organgish-yellow header off carefully, preserving the connector as best I could. I then plugged the sensor into the Duet without any extra wiring - just as you see in the wiki. Lone behold it worked. And even better - I tried homing(without the probe attached to the hot end carriage) and all the motors functioned.

So the BL Touch wasn't fried and somehow shorting something causing the issues - but then what was?

I took a look at the wiring extension I have made and there was a short on the 5V and possibly even to the PWM pin. Here is the kicker - when I measured the voltage, it still read 5V. But all of the symptoms were telling me something was shorting out and draining my available power.

After redoing the cable extensions, I was able to get everything going. Ran several mesh bed test runs, homed a few dozen times. Now I'm running an extended print with what looks like a near perfect first layer.

So anyways, the moral of all of this is you can get some really weird problems setting up the BL Touch, and when I was googling over the past week, I rarely found the exact problems I was having, and when I did no relevant answers. Ultimately, the setup headaches were half my fault, so if anyone having issues reads this, I suggest the following:

1. Don't bother with the reprap configurator for the BL Touch itself - I found that even when importing json configs, I basically had to reread the whole config to check it anyways - I had it decide my Y endstop was at max and not min, despite tabbing back to the endstop page and it showing min. I was so confused when my motor was "stalling" but it was actually just trying to go from y330 to y150 even though it was in the y0 position. It also did inconsistent settings for the BL Touch specific settings. It's a great baseline, and I suggest using it for the base config, then going in and follwing the Wiki and betrue3d's write-up on the configuration.
2. Check, check again, and triple check your wiring. My initial wire-up was shoddy and bit me in the real over just properly crimping new connectors and wires.
3. For the config, especially if you are using both guides and even more-so if you used the reprap configurator, be careful of the terminology to relating to the PWM / servo enable pin. I'm not sure what the reprap configurator is referencing with using E0-E6 instead of H1-H7 indicating which heater your replacing (and relevant to which number you'll see in config). The wiki states "For example, if the E2Heat output is unused, you can use heater 3 which corresponds to the PWM1 connector." which doesn't really bring any light to why it's E2 -> H3 and P3. Especially when in the configurator, you see expansion board PWM numbers. When using the configurator, just be mindful that E2 will be heater3 pin, and E6 will be heater7 pin on the board.
4. The betrue3d guide uses mode 5 instead of mode 9 for the BL touch in the M558 command. I've not noticed a difference between 5 and 9, but in case for whatever reason it's not triggering, it may be worth trying that and to lower the trigger value. reprap configuator set my trigger value to 5000 at one point and therefore wouldn't trigger at all.

If an edit could be made to the configurator, a simple change from "what heater are you replacing" to "Which pin will you be using" with options being HEATER3 (H3) through the rest would be great, since that directly correlates to both the pinout on the board as well as the value H and even P will be in the deploy and retrack probe gcode files.

Now my journey to set up independent Z axis and auto bed leveling beings ...

So just as an update to this (for anyone else who may stumble along this) - part of my problem was that I had assumed running the autotune would automatically save those values to the config (or some other system option save location) but you do have to manually go in after the fact and put the M307 command into the config - so part of my problem was every time I'd reset my machine (either to change settings, install something, etc etc) it was defaulting to whatever standard tuning it has, which just isn't reliable for my heaters. Works OK for my heated bed - but to be fair, it's a silicon matt hooked up to a SSR plugged into the wall - it's very responsive and very fast to heat up no matter what.

Here are the values I ended up using in the config M307 H1 A188.5 C66.1 D11.8 B0. It doesn't look terribly odd. I am testing currently wether I need to use M307 H1 D30 as an override setting or if what the PID tuning picked up will work OK.

Ther thermocouple seems to be stable - no spikes, responsive to touch and accurate to my IR thermal gun.

I will check both of those and get back to you. It seems like the thermister (well, it's actually PT100 thermocouple) using the expansion board. the M307 command might be what I need to get it working decently - it really just might be a lower power heater. Once I'm able to print, I'm going to work towards making a silicon sleeve for it to maybe help with that.

So I've been battling this issue for a couple weeks now - I'd say 1/4 of the time I can get my print head heater cartridge to not throw a fault code (usually saying it's rising too slowly). I've tried everything I can in the ways of PID tuning, raising the PWM percentage as high as 0.9. When it's allowed to heat up, it heats up pretty quick. But most of the time, it starts and either nothing happens (temp doesn't change at all) or it starts rising slowly at first, then progresses quickly to the target temp.

Somewhere I had read a way to increase the thresh hold time in which it will throw a fault, but haven't found a way to just decrease the minimum degreesC/s before it throws a fault. The heat cartridge works just fine in my old RAMPS setup - and I've also tried using it with a DC-DC solid state relay (similar to how I have my heated bed set up) - and I've noticed, with the heated bed, when I tell it to start heating up, the PWM signal is applied immediately (there's an LED on the relay showing it's triggered). With the hot end though, sometimes the relay will never come on, implying that there is no voltage being applied to the H1 pins at all, then proceeds to throw a fault about it rising too slow. Sometimes, it takes a few seconds before it starts - and I have to cross my fingers that it will get past maybe 90C so I can actually reach temp and try to print.

Anyone else have similar issues Any solutions I haven't tried? I've also tried a second heater cart of the same time (ultimater) and nothing. Also, there is no part cooling fan.

EDIT: Also, when trying to do the tuning, I got this a lot: Auto tune cancelled because starting temperature is not stable. This normally happened when I tried to start the tuning at around 35C (while ambient temps are closer to 22) and for whatever reason, as noted above, there just isn't voltage triggering my SSR - so of course it's unstable, it's not receiving any power!

For the Y axis, if you haven't already, make sure to lubricate the copper bushings (utlimaker style iirc). Also make sure there isn't some mechanical interference - stuttering is usually the stepper skipping, which means the stepper is trying to move but can not move the part. It looks like your steps/mm is correct for the system you're on (well, close to 80 or so). Potentially, you could try moving to 32x microstepping and doubling the steps/mm - This will cause you to lose a bit of holding force - meaning the axis will stop easier if there is indeed something causing a mechanical stop and help you pinpoint where that could be. Alternatively, your steps/mm is off for Y (shouldn't be - should be same as X) and if you really wanted to, you could take out a caliper/micrometer and do the following process:

Have the duetwifi move the Y axis 10mm
measure how far it really went
measured/10mm = newssteps/oldsteps is the formula you would use, and solve for newsteps … newsteps = oldsteps*(measured/10mm)

Good afternoon. I recently got my Duet Wifi on friday and have been working through getting it set up on an Ultimaker 2+ Extended style clone (might change it to a CoreXY once I get it running and can print the parts to do that…) Anyways, it's been a bit of a bumpy road setting it up - when it arrived, the firmware was dead (or I it the erase button on accident when first plugging it in?) but either way, had to use the SAM-BA tool to fix that problem, started wiring things up, got most of my parts connected and wanted to start doing some testing before I get the hot bits wired up.

Completely unrelated to my current problem - the SD card came with only the Delta style macros and config setup. Not that big a deal, the wiki is thorough enough to have worked through that and I was able to make my own homing and pretty much rebuilt the config.g file. I noticed just earlier when looking at the recent firmwares at https://github.com/dc42/RepRapFirmware that there are some presets but, as far as I can tell, I don't see any that quite match the ultimaker style machine (then again, I don't know what half those machines are - only Kossel, prusai3, and corexy sound familiar). But I digress, to my actual problem.

So, now that I'm in the process of testing macros, setting up auto bed leveling, and testing some dry runs with the machine, I get constant errors as follows:

[[language]]
Communication Error

An AJAX error has been reported, so the current session has been terminated.

Please check if your printer is still on and try to connect again.

Error reason: timeout

Usually, it reconnects just fine. If it doesn't reconnect the first try, it will after a second or third. I've never had it not connect. The problem I'm finding, is this happens very often, namely when I'm trying to do things in the UI. For instance, I'll be moving an axis or testing the homing macros and I get the timeout error. Also, while not a big deal, I've noticed that there can be a good deal of lag when, say, jogging an axis +/-10 and when the machine finally does it. This isn't a terribly big deal - but usually a timeout happens during funky behavior like that.

Any help on this issue would be amazing! I'll be upgrading to a paneldue soon - once I can print a mount for it, but I'd still much prefer to use the web interface when possible but in its current unreliability, I fear I'll be neglecting one of the main reasons I bought this over other boards.