Hi Paul, thanks for your feedback! Quoteappjaws1 How would you use the "Enforce fan value"? Enabling that option will make the web interface apply the slider's fan value, so one can override the M106 codes from a file being printed. Cura still doesn't generate working M106 codes, and if I print an older G-Code file, it happens that the fan is turned off (or set close to zero) when layers with aby chrishamm - Ormerod
Quotedc42 I think I recall zpl saying in another thread that in his web interface, he computes %complete on the proportion of the file read. Yes, that was true for my last web interface release 1.05, but I've changed it back to compute it based on the filament usage in my current release 1.06. That new version only uses the proportion of the file read as a fallback value if no filament data is rby chrishamm - Ormerod
I've just released version 0.96b of my firmware fork on GitHub. The changes in this release are: Quote - M82 and M83 no longer reset the reported extruder positions - Moved print factor implementation (extrusion+speed) to the Move class - GCodes: All codes report replies with a '\n' at the end - Calling M106 with no arguments reports current fan value in per cent - M112 (Emergency Reset) doesn'tby chrishamm - Ormerod
My guess is that you have a loose connection somewhere at your thermistor wires. If the firmware reads bad temperature values, it will automatically shut down the appropriate heater and a temperature fault will be reported in the message log. If that isn't the case, you can upload your G-Code and your config.g file somewhere and I'll have a look at them. RRP's official firmware version is 0.78,by chrishamm - Ormerod
Ahh, at the same point it stops you say? Sounds like you're using an ancient firmware version. Which one are you using? You should be running at least version 0.78. The message log can be found on the Web interface, but I guess you've been using Pronterface instead.by chrishamm - Ormerod
Doesn't Pronterface estimate the print time when loading gcode files? Has anyone compared its estimation with actual printing times yet?by chrishamm - Ormerod
Hi Flo, sounds like you have a loose thermistor connection. I suggest you check the connectors on the Duet and the ones at your hotend again If that doesn't help, post the content of your message log.by chrishamm - Ormerod
Yep Dave, I couldn't explain it better Estimating the print time this way may seem trivial, but there are lots of factors you need to take care of, and the power of the SAM3X as well as the IO bandwidth of the SD card is limited. I guess that's why nobody has implemented this feature yet. And Dave, to answer your question: The firmware applies only one acceleration to each move, although I guesby chrishamm - Ormerod
Quotejstck The thing is, there are situations where each method will be "the worst", so just saying one in particular the most accurate one is far from straightforward. Best option to give a single value would probably be a weighted average (where the weights can be changed by the operator). I agree. My idea is that all the print estimation times are only approximate values, thus I want to haveby chrishamm - Ormerod
Quoteappjaws1 As you can see the filament is the most accurate at the start of the print and remains quite close to the final finish time but the File estimate is way off for the first 4 hours or so. So much depends on the shape of the printed item that it is hard to know how to improve the estimates without major processing of the gcode file. I wonder how difficult it would be to take the speedby chrishamm - Ormerod
Yep, that is indeed correct. With my firmware fork, you need at least 90°C to retract and 160°C to extrude, but you can override this saftey protection by running "M302 P1".by chrishamm - Ormerod
Hi Pyromaniac, which firmware version were you using before you upgraded to my fork? Do you run "T1" in your start G-code and/or config.g file? Also, at what temperature are you trying to extrude filament?by chrishamm - Ormerod
Hmm, that sounds odd. Can you please post the output of M122 at the time your print stalls and also the content of your setman.g file? I'll try to reproduce this issue later and fix it if I find out what's going on.by chrishamm - Ormerod
Hi Paul, thanks for your positive feedback Interesting to see some statistics, but note the filament usage usually stabilises after the first 3% of filament have been printed. Then it will use per-layer data to estimate the remaining time - maybe I should implement something similar for the file progress estimation in my next web interface release.by chrishamm - Ormerod
Quoteappjaws1 Would it be possible to include another slider on the web interface to control the external fan speed. Yes I think that should be doable, I'll have a look at it soon. Quoteappjaws1 Is it true to say that when new versions of the web interface come out, that the only files that need uploading are reprap.htm and from the js directory reprap.js? If not could we have the facility to lby chrishamm - Ormerod
Hi dc42, thanks for your feedback! Quotedc42 Quotezombiepantslol - Network can be disabled (M552 S0) That seems an odd feature to include. If you don't want the network, don't connect it! I guess you could use it to disconnect the network during a print, but I can't see why you would want to. Well yes, I partially agree. RRP implemented that one to speed up their firmware starts in case no ethby chrishamm - Ormerod
I'm very pleased to release version 0.96a of my firmware fork as it brings some new cool features to our Ormerods. The following things have changed since version 0.89m: Quote Merged in most of RRP's new firmware features from 0.90-0.96 (thanks Adrian/RRP): - G32 runs /sys/bed.g if it exists (file doesn't need be present with my fork though, if it isn't, the firmware will use the points specifieby chrishamm - Ormerod
Hi Paul, two thoughts: - If you specify G10 with the S and R parameters in the config file, the firmware will set the active and standby temperatures right after you turn on your machine. So it's no surprise the heaters turn on right away and the fan starts spinning - IIRC the Duex4 shares its AGND line with the normal GND, which is quite noisy, so you may be better off hacking an extra connecby chrishamm - Ormerod
Have you cleaned the hobbed insert yet? If it slips, probably nothing will come out of the nozzle.by chrishamm - Ormerod
I've just released version 0.89m of my firmware fork at GitHub. I didn't have time to look at the firmware earlier, because I've just moved to Berlin, but now I'm back to printing again Well, this release is just a minor update, but here is the changelog: Quote - Merged in dc42's latest changes from his 0.78t release, especially his bug fix for homing moves with axis compensation parameters setby chrishamm - Ormerod
Hi dc42, you didn't promise any of these, but I hope you consider merging my following changes into one of your future firmware releases Quote - Modify XY homing moves to set the final axis position (either axis min or max) depending on the move direction. I've implemented this in my firmware fork to hopefully add support for the new Ormerod 2 Y-axis, so O2 users don't have to rely on G92 in thby chrishamm - Ormerod
I've just released version 0.89l with additional diagnostics code. If your temperature problem persists, please let me know. dc42's points make sense, can you please post the content of your tpre/tfree/tpost macros from the /sys directory here? Also, what values are displayed in the "Head 1" text box on the web interface at the first three layers? If the target temperatures are displayed properlby chrishamm - Ormerod
I've just released version 0.89l on GitHub. The changes in this release are: Quote M18 and M84 (disable drives) can disable specified axes and extruders only More diagnostics code added Improved file info detection Other minor changesby chrishamm - Ormerod
Hmm sorry to tell you, but your G-Code file has just finished without problems on my single-nozzle machine. I removed the first few bad M106 calls and adjusted the printing temperatures to 250C, 240C and 235C for the first three layers respectively, but those temperatures were definitely set at each layer change. If you notice this problem again, can you please run M122 via the web interface andby chrishamm - Ormerod
jstck, the point is that the Ormerod 1 kit was advertised to be capable of printing ABS, but this was NOT true with the stock ATX PSU. It could very well extrude ABS, but that's pointless if the extruded material doesn't stick to the build platform. I remember struggling with the heated bed to get it to 110°C, but that was nearly impossible with the ATX PSU. At first I tried to cover the heated bby chrishamm - Ormerod
You really don't need that "Relative Es" plugin any more, just put M82 into your start G-Code as jstck already said and you're ready to go If you get poor results at the first layer, you may also want to have a look at this plugin:by chrishamm - Ormerod
Dave, my web interface is basically identical to dc42's fork (version 1.02). There are just a few minor modifications, e.g. M0 is executed on Pause/Reset, so the stepper motors aren't disabled whenever a print is cancelled. If anything goes wrong at the first layer, you won't have to home all axes again. The default X axis direction is still inverted (as of RRP's dev firmware 0.86), but you canby chrishamm - Ormerod
Thanks for your feedback I just had to update the firmware binary of 0.89k though, because the extrude buttons (in particular due to a problem with M121) caused moves to be executed twice with wrong feedrates.by chrishamm - Ormerod
Yes, that one didn't work, sorry. Please seeby chrishamm - Ormerod
As promised I've just released version 0.89k with S3D support onby chrishamm - Ormerod