Posts made by DaBit

We have local variables now. Nice!

Sure, directly painting the surface makes sense. How to get decent resolution is a good question. Inktjet gets you there. Felt markers, meh.

For occasional use hydrodipping might just be the answer. Standard patterns are available as rolls, custom can be done with blank sheets and an inkjet printer (but not any inkjet).

I might want to try it one day. UV-unwrap the object in Blender and use hydrodipping to transfer graphics to a printerd part.

Not much of a braincrunching project (which is usually most of the fun), but a decent option to texture 3D prints could be hydro-dipping:

It can do wood grain nicely.

Requires a suitable inkjet printer, hydrodipping sheets, activator and a bucket of water. I never actually did it, but maybe I might someday.

The CAN bus was made for stuff like this. There is only a delay in the transmission, and unlike many other serial physical layers that delay is fixed and known. So it is fairly trivial to synchronise a clock over all the CAN-connected boards, down to microsecond level. Once we have a synchronised clock, we have synchronised motion.

I cannot look in the head of the developers, but I am fairly certain that clock synchronisation was the first thing implemented and thoroughly tested since it is so vital.

@deckingman: Lack of thrust is for a large part gut-feeling-territory, there is little to nothing Duet3D can do about that. Sometimes it happens that products go in a direction which does not suit you. Vehicle manufacturers do that, coffee machine manufacturers do that, and so on.

If I were in your situation I threw out the Duet3 and went back to Duet2+DueX5 with RRF2.05 or investigate other controllers. Takes a lot less energy in the end.

Another sound here. I am very happy with the speed of progress. Many new releases bring features I can actually use on my quite nothing special printer.

Regarding the effort: last week I set up a Duet2 for testing a motion stage. I needed RRF3+ for that so I could use while loops to iterate the same movement tens of thousands of times. Zip-zap-zip-zap, all day long, all night long. It took me about 20 minutes going from plugging in the USB cable in a freshly arrived board to a WiFi-connected testbed that was exercising the motors running RRF 3.2. The process took upgrading the FW to 3.0, then to 3.2 (somehow going directly from 2.x to 3.2 would not work but I did not spend time on figuring out why), configuring the controller and writing a few lines of G-code.
I am very comfortable with LinuxCNC, I can do the Arduino+stepper drive stuff too, but there is no single piece of kit that allowed me to get up and running THAT fast. Which is exactly why I chose a completely-overkill Duet for the task.

Whatever you buy, you need to learn how to operate and maintain it or find someone who does it for you. Software is not different.

Nice, thanks!

Just considering options at the moment.

Say I want to control 7 heaters+sensors of which 5 are 230V/SSR, and read 9 more NTC temperature sensors using Duet3 Mini which I would want to process in the daemon task, would one or more Sammy-C21 boards connected over CAN-FD work for that? Of course that would need additional hardware such as resistors for the NTC's, a driver for the SSR's, etc. Not a problem for me.

Would the Duet3Expansion firmware on Github work for that with little or no modification? When looking at the pins in the wiki page, can I use PA[04..08] for NTC sensors and PA06/12/19/23 to control heater SSR's, for example?

So, basically, at 180 steps or so the actual vs demanded position deviation of the last motor is more than half a step with the others close to that, with zero load?

That is way worse than what I would have expected...

Basically 2 linear magnetic flux sensors oriented with 90 degree rotation. Rotating a magnet over them give a sin and cos signal from which you can calculate the angle.

Works fairly well. But usually not 15-bit well. A resolver would be more accurate.

[edit]
From the datasheet:

[/edit]

So that's 8.5 bits of precision. The extra 6.5 bits of resolution come in handy for the servo loop, but that is not precision.

That calibration only cancels fixed nonlinearities (and adds stepper imprecision). A slight magnetic short after calibration of changing operating point of the sensor due to temperature is not cancelled.

That's half a step. I would expect a simple open-loop motor to perform better.

On the other hand, I am sure you can interpolate a single rotating magnet with 15 bit resolution, but resolution != precision.
A long time ago I did approximately the same for a customer, but back then it was an entire board with an FPGA, Burr-Brown ADC's and discrete analog frontend. We got ~9 bits of accuracy, the rest got lost in noise and nonlinearities.

Fingers crossed...

I can only speak for myself, but:

• The UKP 13,39 shipping cost: stiff, but I knew that in advance and accepted that. E3D explicitely stated that they would do Fedex only.
• The VAT: did not pay that in the UK, so NL VAT is it. Expected costs. When buying locally you would have to pay that also.

What is left is the cost Fedex charged, 15-20 euros. I do have an opinion on that; they knew they were shipping from UK to NL non-company before they picked up the package, and it is quite a chunk of money for some computerized paperwork. But I also knew that was coming.

Worth it? I needed a board to drive a motor. I could have bought another random board and a Duet3 later, but that would have been just as expensive or worse.

We shall see what the pricing is going to be when the boards are available locally. I don't think the difference is going to be that bad.

The contents are coming from the 8GB Sandisk Edge SD-card that was inserted in the board when it arrived. As-delivered the firmware was RRF 3.2-beta (2?), same for DWC; that was a 3.2 beta too.

Maybe someone swapped cards or images, although the default contents of config.g mention Duet 3 Mini 5+. There is no image on the card for use with a Pi either, but I am not sure if it should have been on it with the Mini 5+.

As a side note: may I suggest putting M550 P"Duet3D" / M552 P0.0.0.0 S1 / M586 P0 S1 in the config of the Ethernet-version as-delivered?
That way the board is accessible on the network out of the box using http://duet3d.local on a regular home network setup. Saves all the initial terminal hassle; since DWC is accessible it is easy to do the config upload from there. A bit more userfriendly.

Before powering the (Mini 5+) board the first time I took out the SD card, inserted it into the PC, renamed the original sys/ directory to sys.original/, copied it's contents into a fresh sys/ and then copied an RRF-configurator generated set into sys/ over the existing files.

There is no Duet3_SDiap_Mini5plus.bin file in the original sys/ ...

Firmware upgrade was done by uploading Duet2and3Firmware-3.2.zip. This initially failed on the missing file, so I renamed the Duet3_SDiap32_Mini5plus.bin and entered M997 S0 manually to perform the upgrade.

This works, I am running 3.2 (2021-01-05) now.

Small bug, or user error?

Renaming the Duet3_SDiap32_Minip5plus.bin file to Duet3_SDiap_Minip5plus.bin works.

If you have it available somewhere you can use some 6mm/8mm inner diameter petrol hose. The rubber kind with a (cotton?) braid as reinforcement embedded in the rubber. Due to the reinforcement that stuff is quite stiff in rotation, due to it being rubber a hose clamp clamps it stiffly around a shaft.

I stumbled over M569.1 in the G-code reference today. Is that already implemented?

In case you have to return the encoder before finishing you tests: I probably have some 2500-line incremental encoders with quadrature output (10000 pulses/rev) lying around over here somewhere. I can miss one or two. If I can find them..
(you may think your mancave is a mess, but I am fairly certain I win that battle)

Your call.

I hugely prefer the lower overall energy consumption (230V->24V conversion is not 100% efficient after all), more reasonable wiring cross-section and faster heatup of a 230VAC powered bed heater.

A 24VDC heater also burns to ashes when it separates from the build plate, and grounding the build plate (and other metal parts) is always a good idea, also in a 24VDC environment.

Keenovo also recommends a backing structure that applies pressure to keep the heater and heatsink in close contact. I did that using some ceramic mat normally used for repacking moped/motorcycle mufflers.