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 ....
Systems Architect, all round gear head, model builder, amatuer photographer, cynical pessimist
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)
it would terminate after 30-60 seconds or so as a timeout
Yup it does ...
Just found this - just in case people thought moving air was easy ...
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 ?
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.
Classic poor termination - keep those terminals tight - check regularly especially high current connections such as heaters.
Said it was the kiss of death ....
So no jolts or odd behaviour - except now the print failed 1hr 14 into the print with Error 1 - Cannot read file.
File reads fine via the Duet GUI, can be downloaded, edited, viewed to the end etc etc
File reads fine with the SD card on the PC - scanned with notepad++ - no defects in file -
I will try again and see if it chokes at the same point.
Appreciated Dave, I was about to report but have refrained since doing so would have been premature - and the kiss of death.
So far running direct with no SBC and 3.2 b 2 I've had a print running 30 mins or so with zero issues so far.
If you need me to do any testing let me know. I've created a completely new SD card to run local and can easily pop the Pi back on.
Duet3, attached SBC.
All updates are done via the console of the SBC.
I've attached the config.g but I don't think it adds much - this problem does not exist on 3.1.1 with the exact same file. I verified this behaviour by printing the exact same test piece using the exact same gcode. 3.1.1 does not demonstrate the behaviour.
I didn't keep any pictures of the ripple - I will have to reproduce - I didn't think this was anything other than my problem - reverting the firmware was a last resort, I wasn't expecting the problem to go away.
The test model gcode is too large to upload uncompressed. It is essentially a 5mm thick box, 75mm sides with a 75mm radius on one corner. Be aware though that this prints fine on 3.1.1.
Be aware - this is a gcode file that has been zipped - the extension should be .zip but I couldn't upload that.
A little obvious - I kind of know this - I run beta on purpose in the hope that issues found may assist the team resolve. I'm not asking for a fix hence the FYI - but I am making those that can fix aware so it doesn't end up in a release version.
This is an FYI. Partly in the hope that somebody with a better understanding of the code than me may have ideas that can be explored to detect whatever 'this' is or may be.
There comes a time with printing that you can't identify whether a problem is
A : You
B : The machine
C : The Slicer / Gcode
D : The Filament in use
E : The day of the week
You get the picture here I hope.
I built a CoreXY based on the highest possible grade of everything, including linear rails, I drive it with a Duet 3. Enough background .... needless to say I have already eliminated the above list.
Recently I've encountered some real wierd issues, all since rolling into 3.2 Beta. I had a strange low frequency ripple 'wavy line' in vertical surfaces that was 10 to 12mm peak to peak, it was totally vertical and not skewed in any way although it was very very slight and you needed a critical eye to spot it (the camera saw it first - I didn't).
Every now and then the print head jerks violently almost like it had been snagged on something, I watched it, it wasn't, no belts were snagged, nothing was catching on the print, no reason for such a violent jolt - and thats what it is a jolt like it releases pressure or jumps back and forth really quickly, it is a very audible 'thud'. It doesn't happen in consistent places and sometimes is more violent than others and is so fast that I sure as heck can't spot exactly what is going on.
I've spent a lot of days trying to figure this and ultimately rolled back firmware from 3.2 beta to 3.1.1 - what do ya now - the problems went away - all of them. There is no mechanical or other issue here - it is 100% been introduced in the code some place. But how to track down what it is ?
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.
Sure and how many times have you messed up .... I know I have .... blank mind / not thinking / forgot a job was running / too much Vodka gone from the bottle ....
This is the Apollo 13 thing where he put the sticker on the jettison switches saying 'NO' ... it is alltogether too easy to have a momentary lapse - at least for me.