Posts made by grizewald

@GeorgeM said in Is the PanelDue display my only option?:

Thanks @jay_s_uk . That was it. I had just plugged in the cable as it was without tracing the lines. Working now.

While I'm glad to hear that you found the problem, you're lucky it wasn't the power wires which were not hooked up as expected. That would have been a much more painful way to learn the lesson.

When it comes to cables, even directly from the manufacturer, always double check them with a multimeter and against the documentation as to what should go where or Murphy will hunt you down and make you pay!

Case in point; I unwrapped a brand new receiver to put in an RC model I was building the other day. I was about to use the programming cable which was included but I reminded myself of the "Check the cable" rule. Wouldn't you know it? Power and ground were reversed. On a cable from the manufacturer which was in a sealed anti-static bag together with the receiver.

Mistakes will happen and if you don't work on the basis that all cables are incorrectly wired until the opposite is proven, then sooner or later, you'll be letting the magic smoke out of something. Inevitably, this will happen when you're in a hurry and replacement electronics are only available from the other side of the planet.

I had big problems with printing PLA with my Mosquito and experienced multiple jams.

In the end, I printed an adapter that let me mount a 30mm fan and the extra cooling cured all my problems. In retrospect, this could have been caused by the fact that my mount fits fairly closely behind the hot end and was probably reducing the air flow. Now, with the larger fan, the fact that the mount is just behind the hot end leads to the cooling air being reflected down onto the print, which is far from ideal for some filaments. So, my next change will be rotating the hot end by 90 degrees so that the exhaust air is not impeded by the mount. This may let me go back to the original 25mm fan, but to be honest, the 30mm fan is quieter and the adapter lets me point the intake of the 30mm fan slightly upwards to avoid the intake turbulence from also cooling the print and print bed.

@jens55 said in mellow nf crazy hotend:

The Mosquito costs more than some complete printers. Why would a sane person pay this much ? What do you get that you don't get with an E3D V6 for example ?
This is not a poke but a serious question because I always wondered why anybody would buy a hot end THAT expensive (unless it's for bragging rights)

The ability to change nozzles without a complex procedure involving needing three hands and working with a fully heated hot end at over 200°C.

Yes, it's expensive, but making the process of changing nozzles ridiculously simple and making it possible to do so while the hot end is at room temperature is worth every penny.

Forgot one thing,

With direct drive, I use a PA setting of 0.06 with a 0.4mm nozzle and 0.03 for a 0.5mm nozzle.

@felt342 That's a very impressive tune for such a long Bowden tube. I gave up trying to get such a long tube to work on my CoreXY and converted it to direct drive instead.

It wasn't that I couldn't get the machine to print nice cubes (and without the warping you have on the bottom of yours), but what worked for one print wouldn't work for the next one.

Direct drive fixed all that and made the printer much more consistent.

Ringing is fixed in two ways: slow down or stiffen up!

If there is a resonance problem, DAA can fix that. If there are other problems with the mechanics or simply exceeding the acceleration that the frame can tolerate, then DAA will not help you.

If slowing down doesn't cure the problem, then you need to look hard at the motion system.

If it helps, these are my settings for the motion system from my V-Core CoreXY. It can print close to 300x300x300mm and runs on 24V with beefy 2A 4.8Kg/cm NEMA17 stepper motors which drive 9mm wide belts.

The theoretical maximums were calculated using wilriker's Maximun Accelleration calculator and other calculators available at reprapfirmware.org and reprap.org

; Motion settings
;
; The V-Core is theoretically capable of the following settings:
; M566 X1200.00 Y1200.00 Z100.00 E3600.00     ; Maximum instantaneous speed changes (mm/min)
; M203 X18000.00 Y18000.00 Z600.00 E3600.00   ; Maximum speeds (mm/min)
; M201 X5800.00 Y5800.00 Z180.00 E3600.00     ; Maximum accelerations (mm/s^2) for X and Y. Z and E are best guesses

M566 X600.00 Y600.00 Z100.00 E3600.00       ; Set maximum instantaneous speed changes (mm/min)
M203 X18000.00 Y18000.00 Z600.00 E3600.00   ; Set maximum speeds (mm/min)
M201 X600.00 Y600.00 Z180.00 E3600.00       ; Set accelerations (mm/s^2)
M906 X1600.00 Y1600.00 Z1800.00 E595.00 I30 ; Set motor currents (mA) and motor idle factor as percentage of normal current

My print speeds are dynamic and depend on things like if the printer is printing infill, outer perimeters or bridges. Print speeds range from 30 - 100mm/s with travel moves at 200mm/s. I use Prusa Slicer and take advantage of the volumetric speed limit to restrict the maximum volumetric speed when slicing to what I know the particular filament is capable of. I find this gives me much more consistent dimensions and interlayer adhesion.

@dc42 said in Conditional GCode and object model variables:

60 years of program language development have taught us GOTO is bad, so I won't be implementing it.

I'm guessing you mean that GOTO is bad for those who don't know how to program. They should certainly be used very sparingly and can be misused to create spaghetti worse than any 3D printer, but they are not bad per-se.

In deeply nested decision blocks, a goto can be a life saver for code clarity. Even in those languages which don't provide a goto but give you a try, catch pattern instead, it still boils down to an absolute jump once it gets compiled.

@Nightreaver said in Faster Z Homing with dual endstop (switch + probe):

Well, my regular travel speed is at 1000mm/min, and probing speed is 100mm/min, so its noticably different.
And I'm kind of afraight to raise the probing speed that much as idk how the probe will react to faster movements... i dont wanna crush my glass bed
So I kind of wanted to use full speed homing to that second endstop.

I don't see any reason why you cannot initially home with the BL-Touch at 1000mm/min. Antclabs, in their own documentation, have suggested using a feed rate of 1500mm/min for the fast homing phase and 375mm/min for the slower probe.

See: https://www.reprap.me/media/support/BLTouch-Classic1122.pdf

How fast will your CoreXY's Z axis actually move at full speed?

Is the tiny amount of time (relative to how long any significant model takes to print) that it takes to home your Z axis really worth trying to shorten?

@chilli The analogue output would indeed work like a switch and the Duet could read that. (You may need to scale the voltage down to 3.3V for the Duet, depending on which input it is connected to and the version of your Duet.)

It's interesting to see how they've used a triangulation technique to get around the problem that David raised regarding simple reflection measurements and the difficulty of measuring femtosecond time differences. That the sensor you have has a repeatability of 4 microns is very impressive and certainly makes it a candidate for a good bed probe. (The printing surface may be important though.)

@chilli Have a look at the following two pages:

https://duet3d.dozuki.com/Wiki/Choosing_a_Z_probe
https://duet3d.dozuki.com/Wiki/Connecting_a_Z_probe

You'd need to find some way to make the sensor support one of the interfaces which already exist.

Most interfaces are very simple and emulate a switch, so all they tell the Duet firmware is that the sensor has been triggered (i.e. has sensed the surface of the bed.)

It may be possible to do something with a Pi, but if you are emulating a probe and need to convert the data from the sensor into a simple switch, the time taken to do that conversion could introduce delay and inaccuracy.

It's hard to speculate without knowing how the laser sensor talks to things.

@chilli I can't imagine that these sensors output any kind of data which the Duet's firmware would understand.

Without support for these devices being implemented in the firmware, it would seem unlikely that you could use them. Most of the sensors which are supported tend to output either a voltage based signal or a digital signal. I'm guessing from the Keyence web site that these actually output measurement data in a text or binary format.

(I can't be 100% sure about this, as Keyence won't let me download any datasheets without creating an account, and I'm not going to do that.)

@mark You might also find this page illuminating: Flyback Diode

Note that you must connect the diode with the cathode to the positive. On all the 1N series diodes (and 99% of diodes in fact), the cathode is marked by a ring at one end of the package:

@mark A 1N4004 diode will work just fine. You can get a pack of 10 from eBay UK for 99P plus postage. See: https://www.ebay.co.uk/itm/1N4001-1N4002-1N4003-1N4004-1N4005-1N4006-1N4007-General-Rectifier-Diode-DO-41/312730999168

My pleasure!

The Duet switches the negative side, so the PWM pin on the Duet is switched to ground. Therefore, you'd connect + to your MOSFET's PWM input and ground on the MOSFET to the Duet's PWM pin.

For your hot end cooling fan, get a 12V one.

@TLAS said in Duet Slicer Integration?:

@grizewald

I don't suppose you use any modern cloud environment, like GitHub, Fusion 360 or OneDrive? It's not about computing power, it's about mobility, universal compatibility, and creating a community ecosystem with ease of access to everyone.

Major advantages of using a cloud technology (or really just web ignoring the buzz word), could involve the following:

• Saving slicing configurations that follow you, regardless of the device.
• Pre/parallel slicing using your standard configurations (view the g-code outputs immediately from your common settings to pick a starting point for refinement).
• Direct access (without installation) to any of the top slicing engines, on any device.
• Repositories of slicing configurations for specific printers, including manufacturer recommendations. Imagine "the nominal Bowden retraction is 2.7mm with a standard deviation of 0.7mm" for ultimakers, etc...
• Direct access (without installation) to custom slicing engines optimized for specific printers and/or setups. Code and slicing setups for multi-color materials or multi-tool setups that can be easily shared.
• Machine learning technologies that flag common failure settings for your geometry. "Changing to a 0.25mm first layer will increase the probability of a successful print for your printer by 20%"... etc...

Edit: I do agree with you about the personal network. I'd love to see whatever 'cloud' system is developed to have universal compatibility with a local network and distribute tasks / settings to all computers on that network with a lot of the benefits of a cloud but not actually leaving your own network.

I confess I was being rather cynical in my comments, probably because I've seen so much buzzword marketing and empty promises made in the computing industry over the decades. Remember "the paperless office"?

I do use web based services in my job and I personally collaborate with others on open source projects via GitHub etc, but when it comes to my personal data and computing resources, they stay firmly locked behind my firewall and under my control. I was always wary of operations like f***book and other "it's free because you are the product" services and time has proved my caution to be well founded.

I would not personally use OneDrive for anything other than storing obfuscated and encrypted data where I am the only person in control of the encryption/decryption software and associated keys.

My employer uses all the latest fads like Jira, Office365, Dynamics, etc, etc. My personal view is that they are probably in breach of the GDPR (despite them harping on about how much good work they are doing with GDPR compliance) and certainly running the risk of exposing confidential business intelligence to third parties with sufficient resources and interest. It will come back to bite them in the end and every time Microsoft or Amazon's cloud servers experience outages, they burn countless amounts of money in lost productivity.

So I'm far from adverse to new technology and new ways of doing things, but I tend to look very critically at the business models behind new services and what their security and privacy implications are.

@TLAS said in Duet Slicer Integration?:

Maybe at some point a // Slice on cloud could be implemented very easily. Essentially the same thing as the 'Slice on Computer' just over the internet rather than your local machine.

Why on earth would I want to pay someone like Amazon to perform trivial computing tasks for me when I already have countless thousands of MIPS on my own, private network at home?

It seems just as pointless as reducing my choice and slowing down the process by having a slicer integrated into the Duet web interface running on a Pi.

As others have rightly pointed out, getting the right g-code for a good print depends on many factors - the model being printed is one of the most important ones. I fail to see what Pi integration, a fixed choice of g-code generator or farming trivial computing tasks out to a third party brings to any 3D printing workflow, apart from increasing the buzzword score.

Maybe we can slice on the blockchain?

My bed looks horrible:

But the firmware happily corrects for it.

You might notice that I'm probing 225 points over my whole 295 x 275mm print area rather than the nine that you are probing. As you have a BLTouch, you should be making a detailed map. The firmware interpolates the actual height at any point by using the four closest probed heights. If you use a very coarse mesh like yours, it's effectively just guessing how much compensation is needed.

Like Frederick says, get your bed as level as you can. You can use your probe in manual levelling mode to help you. See: Manual Bed Levelling

Once you have done that, create a new levelling map with plenty of points and see how good your first layer is then.

This is purely a guess as you have not really given us much information to work with, but:

@JadonM said:

... no issues until I redesigned my x carriage

If it worked fine before, then I'd say your new X-carriage has a problem with alignment to the bed. The Duet firmware will correct properly only if the levelling mesh is created properly. If the motion system does not move correctly and maintain the proper relationships between the X, Y and Z planes, the firmware has no chance to correct for that.

I'm still only using one extruder, but what I can say is this: if you already know Slic3r, then the Prusa Slicer is far from "only geared towards the Prusa printers".

I've been using Cura exclusively for several years, but recently got bored with the fact that the materials settings and print profiles don't really work in any useful way if you have a custom printer. I'm sure they work fine if you have an Ultimaker.

So, having previously found Slic3r to be unpredictable, to say the least, it was with some trepidation that I downloaded Prusa Slicer...

It turned out that my fears were misplaced. The latest 2.1.0 version is very good indeed! The Print, Filament and Printer settings mesh together logically and efficiently. You absolutely don't need a Prusa printer to take advantage of the settings system. My printer is a big CoreXY with a Mosquito hot end and BMG extruder. It's working very nicely with my printer and producing some great prints.

I particularly like the volumetric speed limit; it's great for ensuring that you don't accidentally break the speed limit on touchy filaments like Colorfabb's PA-CF.

In contrast to Cura, Prusa Slicer doesn't roll over and die every time my machine gets an update for the MESA OpenGL libraries. If it carries on pleasing me like it has done over the last month or so, I may be removing Cura from my computer and switching to it permanently.