Quoteappjaws1 Quoteantlvk ok it works with your new firmware but having problem with web control extruder control what ever setting i use also only load by 1mm i cant load 400mm, it will take ages to load my filament, lol I think the Head needs to be active and up to temperature for the extruder control to work. Yes, that is correct, My firmware fork has cold extrudes disabled by default, howby chrishamm - Ormerod
I wouldn't use a Python script here, IMO it makes sense to modify the firmware read those values right away I've just put a another binary on , which should recognize the filament usage generated by S3D.by chrishamm - Ormerod
Thanks for your feedback!by chrishamm - Ormerod
antlvk, that sounds like a temperature fault to me. Can you see anything unusual in the message log? I suggest you check your wiring again and upgrade to 0.89j. Paul, I've just released 0.89j on GitHub. This binary contains most of dc42's changes for 0.78s, including his modifications for G10 offsets, but I haven't merged in his new LCD code yet. If you give it a try, please let me know if it'sby chrishamm - Ormerod
Your config file looks good, so I figure it has something to do with your start G-code. Can you please attach the complete G-code file you were trying to print?by chrishamm - Ormerod
Interesting. If I get this right, I would implement tool offsets this way: - I think in the first place axis limits should be specified for the raw head position only; when specifying offsets using G10, axis limits should be reduced by the min+max offsets. OTOH, M208 must take care if an offset was specified earlier and adjust them properly - This way when an endstop is hit, we can still rely oby chrishamm - Ormerod
I've just released version 0.89i of my firmware and version 1.03 of my web interface fork. Apart from a few other changes, this updated firmware is now able to queue non-moving G-Codes and to execute them just-in-time. This enables users to utilize the full potential of filament cooling using M106/M107 and should generally resolve a bug where non-printing G-Codes were executed too early. These chby chrishamm - Ormerod
Can you please post the output of M208 and M122? The latter one should tell you if all bed compensation points were set up correctly.by chrishamm - Ormerod
It's a good idea you decided to update, there have been major improvements of the firmware since version 0.56 - you won't be disappointed. I presume you're using the latest version of dc42's firmware fork, and as of version 0.78k, the default direction of the X-axis has been inverted. You'll have to turn around the X-axis connector on the Duet to get it moving correctly again. To get the extrudeby chrishamm - Ormerod
Quotejstck My guess is that the M106 command is executed right away, while the G1 commands are queued up / buffered, so the M106 is then done "too early" relative to the moves. Can this be the case? Yes, that's correct. At the moment G0/G1 moves are fed right into the look-ahead queue and not waited for unless they're intended for homing, so other commands can be executed earlier than expected.by chrishamm - Ormerod
Hi dc42, I did experience a problem with earlier 0.78 builds where I was missing filament during prints, I believe I even sent you a test file to reproduce this a while back. As a result, I implemented a temporary work-around in DDA::AccelerationCalculation, which seemed to resolve this bug. But now I think it's well possible this issue was somehow related to the faulty timeStep calculation in thby chrishamm - Ormerod
djar, have a look at M301 in conjunction with the 'S' parameter:by chrishamm - Ormerod
My guess is that there is still an issue in the Move code, because some extruder moves are not performed too well. I added a work-around for an extruder issue a while ago, but it isn't perfect, it just conceals the actual bug. Especially during top infills, the selected extruder should accelerate and decelerate the same way the print head does, but I feel its feedrate is quite constant. If the exby chrishamm - Ormerod
I found manual Z-probing quite difficult as well when I was done assembling my Ormerod, but fortunately dc42 offers a solution for those not being satisfied with the stock IR probe: I can really recommend that one, because it has been giving me stable readings since I mounted it and it works well on (almost) every bed material. Once the probe has been set up, it's quite easy to test different Zby chrishamm - Ormerod
I really like Cura for some prints, but I found it quite annoying that it doesn't replace the filament usage tags properly in its G-code output files. For that reason I decided to look at its internals to fix it until a new Cura version is released. With my latest firmware 0.89f, the filament usage is read from both the beginning and the end of a G-code file, so the print progress on the Ormerodby chrishamm - Ormerod
Yes, that is correct. I usually run G28 (Home All) and then G32 to run the initial bed calibration on my machine. If you're using my fork, you can connect the Sense line to pin 10 on the Duex4 expansion header.by chrishamm - Ormerod
Thanks for your work, dc42, as far as I can tell all your changes are working nicely And sorry for introducing that M20 bug, I really don't use Pronterface any more...by chrishamm - Ormerod
Hi Paul, M557 is used to specify the probe points, and as you suggested you can specify a fifth point (P4) to enable 5-point bed compensation with either dc42's or my fork. I always run the M557 commands in my config file, although I use 4-point bed compensation only. I don't think it matters where you execute M557, as long as you run it before you start G32. G30 only probes the Z-height at the cby chrishamm - Ormerod
You may use either my web interface fork (https://github.com/zombiepantslol/OrmerodWebControl) or dc42's web interface. My latest 0.89f release should be compatible to dc42's 0.99 web interface as well.by chrishamm - Ormerod
There is still a networking issue in RRP's and dc42's firmware forks, and it's possible this issue is somehow related. My firmware fork already contains a potential fix, so it would be interesting to know if this issue also occurs with my latest firmware release. Is anyone willing to give it a try and report if this problem persists? If it does, I'd appreciate a Wireshark dump so I can take a looby chrishamm - Ormerod
Looks like your SD card isn't recognized by the Duet, so I suggest you try another Class 10 microSD card. I remember when I got my Ormerod, I was facing the same problem, but with another one I got it working. I presume you're talking about the line ending in the Arduino IDE serial console. To get the Duet to recognize commands, you should set it to NL. That way it should respond to any G-Code.by chrishamm - Ormerod
Hi, if this was caused by a bed level compensation, only the first few layers would look bad, but my guess is that your extrusion temperature is too high. Either try to reduce that one or print a few more pieces at once, giving each layer more time to cool down. But still, an accurate bed level is critical to getting good printing results.by chrishamm - Ormerod
I'm sorry to hear that Dave, I hope they will send you a new one. Thanks for the warning though, it's good to know the coating doesn't tolerate acetone. QuoteVortyZA Well! When it DID come off by itself, it had pulled off a sliver of glass of about 1mm thick and a good proportion of the size of the base of the part! So. It IS possible to adhere too well! Yep, I can confirm that - the day I reby chrishamm - Ormerod
Which firmware, homing files and Z-probe are you using?by chrishamm - Ormerod
You shouldn't specify a minimum axis limit for the Z-axis. Use G31 Z-0.2 instead.by chrishamm - Ormerod
I modified the x-carriage a few weeks ago so I can add a cable tie to it, you can get that part from here if you have one of dc42's Z-probes.by chrishamm - Ormerod
Quotemuggi Hi zpl, But please wait After print for cooling down the plate. If you pull down the print with force... The coating will go off the plate!!!! Hi muggi, I always wait until the temperature decreases to less than 60°C, then my parts usually pop off automatically. But what's concerning me is the fact that the coating looks a little bit lifted at the perimeters. I hope this is not a siby chrishamm - Ormerod
I've got one of these alu plates, too, and I'm quite satisfied with it so far. It works well with ABS and I can use my standard hot bed temperatures without any problems (120°C for first layer, 90°C for all others - gives me absolutely warp-free prints). I hope the coating will last for a while, but it's all looking good at the moment. I will report again if I experience any problems.by chrishamm - Ormerod
I've just pushed my latest changes of my firmware fork 0.89d to GitHub. It is based on dc42's excellent 0.78h firmware and RRP's development firmware 0.89. I haven't changed very much in this firmware release, but with my latest fork of the web interface you can already view the fan RPM if you connect the tacho line of a 4-pin PWM fan to pin 25 on the Duet or to pin 10 on the Duex4 expansion heaby chrishamm - Ormerod
Nice! I can already confirm these changes work, I did a 3-hour print yesterday with your changes for 0.78g and everything worked well. Don't forget to merge in my networking changes sometime soonby chrishamm - Ormerod