Best posts made by Garfield

Well I'll be .... think of an adjective

This place is full of genius ... works ...

It's official - going senile ....

Still going to try the CURA and the 'modded' version, and ideamaker ....

Sorted - SSH route works a treat much appreciated.

It is probably best to earth bond the frame of any printer, not forgetting the bed as this deals with static electricity that is produced during operation, this allows it to sink to ground without going via your electronics.

I would not bond the frame to an isolated ground for this reason but a lot depends whether your power supply is an 'isolated' one or not - you may find its ground is already earth referenced if it isn't an isolated supply.

As for connecting cable shields / screens these really shouldn't be connected to an earth reference but bonded to the circuit ground. This topic could easily stray into RF generation and rejection and such, you absolutely must not ground a shield at both ends.

I think the part that many find difficult is that ground does not mean earth, ground is merely the reference point for the circuit itself, earth is something entirely different.

What is unfortunate is the standard of many low end PSU's, given the propensity of folk for seeking the cheapest they are likely to encounter some real nasty stuff that I believe isn't safe to use. I think a problem coming from this is that most people won't know how or be able to identify a poor PSU so 'erring on the cautious side is always preferred - if in doubt earth it.

My PSU for what it is worth is not part of, nor is it attached to the printer frame, yes my PSU chassis etc is grounded but it is not neutral referenced, so the AC it produces is floating and isolated. It is totally overengineered but that's the OCD in me.

(My PSU on the CoreXY is a Balluff BAE0003, on my Prusa I run a PULS SL20)

No complaints here, apology not needed, got into the RC stream, knew the risks, happy to help diagnose and fix.

I started work on a test plan but it is kind of hard to know what to test beyond normal user interraction, when things blow up as a result of previously functional code it is hard to know how to report it, harder to know the information needed to assist in the debug / analysis / remediation.

I find it frustrating and interesting - just sometimes it is more frustration - and even then more frustration at a lack of ability to trace through the fault.

Blunt question - Is it possible to seperate the apps such that loss of DCS does not prevent access to the web console, yes I know information won't be updating but a big red status flag 'No DCS Communication' or similar could be added. Make it possible to access diagnostic logs and still be able to edit .g files from the web gui. Possibly have some 'macro' to collect basic diagnostic information for submission.

I'm not a linux fan, I don't fully understand the code, I'm trying to understand, sometimes the frustration hits the keyboard.

You want me to do some tests just reach out, I think I'm getting pretty good at switching versions in and out, which is a big thank you to all that have stepped in and helped.

@jay_s_uk well I'll be - never had to do that before - but it worked - many thanks

Come now - you asked the questions, that's more than some do, so to say you know nothing is a little defeatist.

Electrickery is a subject that has it's share of complications for sure but nothing that can't be learned, you're aware enough to ask the correct questions so you do know something.

I'd keep the AC earth and DC grounds apart.

Power your DUET through a decent quality 12V or 24V DC Isolated power supply - Meanwell / Cosel aretwo brands that spring to mind that are pretty decent. Try to avoid the unknown cheapest you can find as it could be expensive in the long run.

I don't know that much about the CR10 and I'm not in Germany that often these days North or South, last trip was 4 years ago to Berlin.

What specifically is concerning you ? how do you power the CR10 currently ?

The way this week has gone so far you're not wrong ...

Just found this - just in case people thought moving air was easy ...

Why cooling fans are so hard, and some preliminary testing

Classic poor termination - keep those terminals tight - check regularly especially high current connections such as heaters.

No problem with OT, or jokes ... I can print the same part with 3 different slicers and the impact this has on the print quality / finish on the SAME printer is revealing. Slic3r and the Prusa offspring for instance put rubbish little dabs in places where a solid infil would make much more sense - added perimeters to overcome some of this nonsense. Simplify bridging is appalling, CURA lacks some finesse and is proving tricky to set up even using the same numbers from a successful profile in Slic3r ...

Could waffle all evening ... can already see a defect on the surface of a part that's printing - totally temperature related but if you get that bit correct the rest of the print suffers ....

This comment in their text is somewhat concerning ....

"Alloy 5083 also retains exceptional strength after welding. It has the highest strength of the non-heat treatable alloys but is not recommended for use in temperatures in excess of 65 °C."

You know I've not looked, you're probably correct as I've just looked at some gcode produced by it and theres no conditions present, hadn't really considered the slicer's part in all this.

So I guess the question becomes can the 'Printer' automatically add stuff based on specific conditions such as change tool, finish print, start print - so that slicers without the capability are accomodated ?

I'd like to see temperature widgets, single sensor ones, each could have its own 'config'

I'd like to be able to set the scale / zoom in, as in display every value received if I zoom right in, not simply once per minute or whatever it does now.

I'd also like the ability to download this information.

I'd also like to be able to download control output as a 0 to 100% value alongside the temperature that it serves so that I can assess stability of control / lag in the system especially the heated bed as I want to assess the impact of various 'insulation' materials.

A 240V AC 400x400x6mm piece of aluminium plate radiates a lot of heat not only on the top surface and I'd like to manage that better - would be nice to be able to measure the impact on control input vs temperature.

@chrishamm

Running direct on the Duet3 I now encounter 'other' issues not encountered via the Pi

Error: Cannot read file, error code 1
Cancelled printing file 0:/gcodes/Jacuzzi Cushions.gcode, print time was 2h 12m
12/21/2020, 5:11:07 PM 	M32 "0:/gcodes/Jacuzzi Cushions.gcode"

File 0:/gcodes/Jacuzzi Cushions.gcode selected for printing

12/21/2020, 5:04:48 PM 	Error: Cannot read file, error code 1
Cancelled printing file 0:/gcodes/Jacuzzi Cushions.gcode, print time was 0h 35m
Error: Cannot read file, error code 1
Warning: Failed to read header of G-Code file "0:/gcodes/Jacuzzi Cushions.gcode"

This is not on a cheapo SD card either, it checks out fine, the file can be read without issue. No I can't upload the file, the site won't allow compressed files and as a gcode file it is too large (7,097KB).

This file fails in different places - the fail point is not consistent. When this happens the printer does not behave in a friendly manner - it just stops where it is, it doesn't park the hot end although it does turn off the heaters.

Time to have multiple SD cards to hand, time to create a new RPi image .... I'll let you know if the plugin problem goes away.

I was planning on an end switch mounted on each of the 3 Z leadscrews which are fixed to the bed.

This is just to get them back into a known state.

I still plan on Z probing to set the final first layer height / mesh bed level etc.

I've designed for an induction probe (Prusa's) but I'm also considering putting a BLTouch into service.

I guess I'd need to to an offset for the probe - which for my induction probe is X-27 Y-7 from the nozzle tip centre to centre - but I've not got that far yet.

@chrishamm it hasn't changed in a while now but it is attached here. config.g

Powered up this morning and still shows 'Starting' ...

Many thanks - all this fun stuff you get to learn just because you got into 3d printing, I find it almost as much fun as building the models that I got into printing for, it has become an interest for me in its own right.

@chrishamm Confirmed - if I remove M501 the 'starting' becomes idle. if I add a config override but leave the M501 the starting becomes idle, it seems to be that the system expects to find a config override if M501 is used and gets stuck if it can't find it.

This is what impacts the status screen updating and the print going straight to 'complete' - I just verified it. The print however will continue and completes as it should.

Well my bad I found the location - I read the K1 but failed to spot that 667 had changed to 669 so this is definitely a PICNIC problem

(Problem In Chair Not In Computer)

No worries, appreciated - you can always rely on users to do the unexpected. I never realy thought about the override file, never used it, suppose I should have realised what M501 actually did. It's one of those things you do early on then forget about - until it bites you .....