Posts made by David J

Thank you - I'll experiment later today.

I can't do the second option - my thermal fuse will pop before I get to 125C.

Thanks - I understand what you're saying.

But surely that means going into the code? If so, it really isn't within the spirit of the Duet boards for the user to have to change code, is it? From the outset, it was always done via various config files.

Or have I got the wrong end of the stick (again)?

Oops! Sorry about that. When I started this query I knew it was the bed, but somehow my brain said "hot end" a few days later.

The bed is a 240v one controlled by an SSR - yes, it could get to a very high temp so the warning is valid, apart from the thermal fuse that's in the circuit (which the Duet doesn't know about, obviously).

But why does it show on the PanelDue, and not on the web interface? If the web interface said the same thing then I'd understand.

And can I do anything to stop it showing?

Attitude? Moi?

...actually, it's frustration. This warning message doesn't appear on the Web interface as there the system doesn't think it's important enough to report.

And it's not a particularly powerful hot-end - it's just an E3Dv6 with a the usual heater, albeit at 24v. I can't remember what the wattage is, but they only do 2 - standard (30W) and slightly higher power (40W). I believe that I have the 40W one (I'll have to check). This is a high-temp combo, rated up to 285C, so getting a warning predicting that the temp could reach 236C is rather nonsensical. But this doesn't alter the basic issue - why aren't both interfaces reporting the same warning?

So - no real answer then?

I know it goes away - that's quite obvious! It's just a nuisance that used to appear on the web interface and, somehow, it got turned off.

If it's not important enough to appear on the web interface - i.e. the default, MAIN interface - why does it have to appear on the PanelDue?

I have now got my PanelDue 7i in an enclosure and mounted on my CoreXY printer. All works very well, apart from an annoying warning message displayed shortly after start-up.

I have a vague recollection that I used to get this message on the web interface but I think I was told how to turn it off.

Is there a way to turn this off on the PanelDue?

Thank you.

Recently I became very confused (again) about the M500 command - I made changes to the Z offset in the G31 line within config.g but these weren't carried over into the config-override.g file when I sent an M500 command. I did a search on this forum and found that it's not supposed to any more!

But now I have a config-override.g file that has 3 G31 lines within it, probably there from way back, and most likely shouldn't even be there.

Can I just delete them?

@deckingman It's OK - I spotted that one!

I'm good now, I think. All seems to be behaving itself... (he says quietly)

Once I've finished printing a 3DBenchy I'll be designing my multi-part PanelDue enclosure. I've got it sorted in my head, just need to get it into OpenSCAD. If it works, it will be published!

OK - I get the message - RTFM!

Thanks again David

OK - I've updated the firmware and the web interface. Now, when click on home all axes, I get the error "G0/G1 insufficient axes homed". I also get this error when I try to do most things. Also getting "Heater 0 appears to be overpowered" error.

Presumably there were some config changes between version 1.19.2 and the latest - where can I find details?

And the other problem is... I can't print an enclosure!

All the designs I've found for the PanelDue 7i come out to around 205 - 210mm, and I have the choice of a 200x200 CoreXY or a 230mm diam Kossel. Sigh.

Never mind - time to design a 2-part front panel! It will be mounted on a backing plate anyway, so there's no problem with it falling apart in the future.

UPDATE: I've now received my PanelDue and wired it up - and it's mostly working.

The only problem I'm getting is that it can't run the macros. It lists them, but when I select one it comes up with

Macro file "0:/macros/<filename>" not found

Where <filename> is the correct name for whatever I've selected.

Odd that it lists them but can't find them to run, but maybe an update is required to get this working properly.

Now I need to get an enclosure sorted (I've seen yours on Thingiverse!)

Thanks David.

Am I right in thinking that it's the reprapfirmware.bin file I need from that location?

And should I use the DuetWebControl-1.22.6.zip with that?

(It's been so long since I updated this thing - I'll have to go and find the instructions!

David

It's been a very long while since I've felt the need to access this forum - my Duet board hasn't required attention for a very long time, which is a testament to its functionality and reliability. Now I may need to make changes as I am awaiting delivery of a PanelDue 7i from Ooznest. I am wondering if the firmware I currently have loaded will match that in the display.

My current setup is:

Duet 0.6 (genuine, not clone)
Firmware 1.19.2
Web interface 1.19

Now this is probably well out of date, but it's been working well on my CoreXY and I hadn't felt the need to update!

As far as the wiring is concerned, I have no problems. Also, I'm using the on-board regulator rather than the add-on one, so the documentation suggests that I will have no trouble supplying power to the display.

So the help/guidance I'm seeking is:

1. Will the PanelDue work with this firmware, or will I have to update?
2. Where will I find the firmware if I need to update? I have looked, but it's not easy to identify the version for this old board.

All advice gratefully accepted,
David

And now it works… many thanks!

David - is it worth noting that gotcha in your IR sensor instructions? I'm sure I won't be the last to fall for that one.

D'oh!

Well called - there it is… hiding in plain sight.

Call I just delete that from config-override.g?

DON'T PANIC - I've fixed it the proper way (set the parameter on the command line, then M500)

I have just had to take the nozzle out of my E3Dv6 for cleaning, and now I can't get the height right. Regardless of the value I put in the config.g file's G31 command, after the Duet is reset the nozzle comes down a little too far and grabs the paper too tight. Lifting the nozzle 0.3 gives me exactly the clearance I want. What's confusing me is that it seems that no matter what value for Z I put in the config.g file, the clearance always ends up too small, and Z+0.3 always sets the gap right. It's as if whatever I put in the config.g file is being ignored and it's still using an old value from somewhere.

My setup:
Duet 0.6 running 1.19.2 firmware
V1.2 mini height sensor board
I do use bed mapping.

The process I followed (from the Mini height sensor board web page):
1. Heat the bed and hot-end to working temperature.
2. Home X and Y, then move the carriage to the centre of the bed.
3. Lower the head until the nozzle just grips a sheet of thin paper.
4. Send G92 Z0
5. Raise the head 5mm and remove the paper.
6. Send G30 S-1
7. Read the value for Z in web page, or from M114 (I get 0.787).
8. Put the value into the M32 line of config.g (G31 P500 X0 Y0 Z0.787 ; Set threshold and offsets)
9. Save config.g and accept the Duet reset.
10. Heat the bed and nozzle again, home everything, and retest.

This is all very frustrating, as this setup has been working happily for many months. However I do seem to have problems every time I try to set the nozzle height… Am I missing a step here? Am I doing something wrong?

One other reason for me using Cura is that I find slic3r very flaky - it sometimes crashes when I add a STL file, for example. I also find the whole structure of slic3r inconvenient - I have to have 10 or 12 different setup files simply to accommodate the different diameters of filament I use. In Cura I just find the relevant line and change the number. The same goes for infill, etc.

@biscuitlad:

I would like to use Cura, but it crashes under linux. The python gui seems to have had this issue on early versions too.

How up-to-date is your linux kernel? My installation of Cura used to crash regularly until a kernel update fixed a bug in Mono - which was something that the Cura author couldn't work around.

The Mono bug went away about a year ago, so if your kernel is older…