Posts made by Eumldeuml

@dc42 Sorry, apparently I misread your statement somehow. Thanks for clarifying!

@dc42
Two more questions after buying the Expansion Breakout board:

1. The differential enable pins switch between on and off with 5 kHz when the printer is idle and also when a move command is given (though the motors won't move as they are in alarm state due to the fast switching). Disconnecting the enable wires does work, although I'd like to be able to switch the motors off via software

2. Do I need to disable the drivers on the Duex5? When moving X or Y, there is a warning in the console that the phases might be disconnected (which they technically are, as there is nothing connected to the outputs). When I disable the drivers, the servo motors start moving very slowly upon startup of the Duet and on the PanelDue there is a warning about overtemperature of those drivers.

@dc42 Alright, thank you very much for the information!

Hi all!
I just wanted to confirm something from the documentation. First of all, my (soon-to-be) printer is a CoreXY toolchanger with six independent tools that runs with a Duet 2 Wifi and a DueX5. That means, from the 10 integrated stepper drivers I need 7 drivers for tools and Z axis. The XY system runs on two JMC stepper servos that I need to connect to one of the boards.
From what I read in the documentation, this is either done

• through the expansion header (which is occupied in my case)
• with the pass-through connector DB S/D/E on the DueX5 (which requires the board to be put into DueX2 mode which limits my available stepper channels?..)
• or through the CONN_LCD connector.

I plan to go with the last option as it doesn't seem to have any drawbacks. Is this valid?
Also I want to use the PanelDue 7i which I intend to connect with the four-pin connector. This won't allow me to use the SD card anymore but I'm pushing gcode over WiFi anyway.

I'll be very glad if someone could tell me that my approach is good or that I'm overlooking something.
Thanks and have a great weekend!

From my understanding about injection molding it requires very high extrusion speeds. In commercial machines they melt the plastic in the heating/compression zone and then push it into the mold via hydraulics (or maybe also pneumatics) in fractions of a second. So depending on the size of the mold even a high powered extrusion system from a 3D printer isn't gonna cut it sadly. But I like the idea, it's quite novel!

The WiFi version is v1.23 so that seems to be the current one.
I'll try using the new DWC before deciding if I want to go back. The new design has some improvements that I really like
Also, the .json files are now visible in the systems folder. My guess is that it has to do something with the option of storing the settings on local storage (although I don't know if "local" means on my computer or on the Duet).

The older firmware worked for me so I never bothered updating it. "Never change a running system"
Not having to change my config files convinced me to try updating the firmware and the DWC files. That fixed the scrolling problem but now I have to get used to the new look. At first glance I think I like it though

I haven't found the .json files in the DWC file browser so I suppose you can only see them when the SD card is plugged into the PC? This question is for clarification purposes only.

Anyway, thanks for your detailed answer Sometimes the easiest solution looks like the hardest...

Hello all!

Some time ago I encountered a weird problem within the Duet Web Control: Whenever there's a scroll bar in the browser window (like when viewing the G-Code file list) and I scroll down, it automatically scrolls to the top again after about two seconds. This is kinda annoying when editing the macros in the system folder because you have to click very quickly on the file or else you'll miss it.
I'm using Firefox version 86.0 but the problem exists for quite a while now so it's not that specific Firefox version. I've also tested Chrome Portable v89.0.4389.90 and the same problem occurs. So I think it has something to do with my Duet firmware but I don't know where to look. Any help is greatly appreciated

M115:
FIRMWARE_NAME: RepRapFirmware for Duet 2 WiFi/Ethernet FIRMWARE_VERSION: 2.02(RTOS) ELECTRONICS: Duet WiFi 1.02 or later FIRMWARE_DATE: 2018-12-24b1

Regarding the settings for the scope, I'm not sure which ones you mean.
The step pulses are what you'd expect but the DIR signal is not. On the picture you can see both signals, STEP on top, DIR below. The sampling rate probably isn't high enpugh to catch all the pulses (pulse width is set to 2 µs) but otherwise you wouldn't be able to see the whole spike on the DIR channel.

Hi all!
I'm trying to read the signals coming from the E2_STEP and E2_DIR pins on the expansion header with an Arduino. For every step pulse while DIR is high I want to increment a counter and for every step pulse while DIR is low it is decremented.
The problem I encountered is that the DIR pin doesn't have either a high or low state but instead just sends a positive/negative spike for each direction change. I checked this with an oscilloscope.
Is this the expected behaviour? From what I've read the DIR pin should either be constantly low or high.

Btw, I know that the Arduino Mega uses 5V logic and the Duet WiFi outputs 3.3V at the expansion header but for now this doesn't seem like a problem.

@fma You are right, that's why I asked the initial question (we closed the loop, so to say :D)
A printer that tilts the bed to tram it is already a 5-axis machine (or more like a 7-axis machine, if you count all the axes of the printer). What's missing is a software, that allows for non-planar printing and is fire-and-forget like a regular slicer. Still a long way to go I guess...

@fma Sadly I haven't tried anything of what I mentioned since I don't have the hardware (or the money and the time...).
But I think the problem mostly comes down to software while the hardware isn't nearly as challenging.

Is there a way of testing that without modyfing the board itself? A resistor in series with one of the connecor wires perhaps?

I've tried it with P8 now and the results are as following:
On blue tape it gives me a consistent reading of 1000 at 19 mm and below (Z=0 is the height where it gives me the same reading on Kapton + aluminium). But the value jumps between 0 and 1000 erratically when it's over blue tape and between around Z19 and Z25.
When the probe is over the scuffed Kapton on blue tape, it shows 1000 at around 18 mm and also jumps around if a little higher than that.

In all cases the red LED on the probe only lit up at very close distance. I guess that this is hardware-related as that shows when it is triggered in analog mode, right?

I tried homing on all three different surfaces (although with a reduced speed) and it did work on all of them. It Trigger distances are all in the range of 25 to 35 mm above the surface which sounds a little bit excessive. From what I could measure, the consistency is quite bad on all of them (Blue Tape ~0.2 mm; Kapton on Blue Tape ~0.2 mm; Kapton on aluminium ~1 mm).
I also did the same test for consistency with the standard analog mode and it was accurate to about 0.02 mm.

My settings are:
M574 X2 Y2 S0
M574 Z1 S2 (the two M574's are in seperate lines so that I can set a different S parameter)
M558 P1 H2 F2400 T48000
G31 P500 X0 Y-47 Z0.78

Thanks for your replies!
@theruttmeister: Angling the probe could be a solution, I'll try that later!
Squares of blue tape is kinda impractical since I'd like to use mesh leveling and I use about 40 points... Also I can't live with the fact that the mesh then won't represent the exact surface. The curse of a perfectionist I guess...

@gtj0: I use it on a Duet WiFi which uses analog mode according to the website. Is there a way to switch to digital mode?

Yesterday I also found some weirdness in the readings of the probe which are displayed in the DWC as numbers from 0 to 1000:

Kapton on Blue Tape:
Z0.6-: 537 (triggered)
Z0.65+: 466
Z1.6+: 0
Z5.95+: 466 (possibly because of the surrounding blue tape, since I only used one strip of Kapton for testing purposes)
Z20.6+: 0

Kapton on Blue Tape after scuffing it up slightly:
Z0.65-: 537 (triggered)
Z0.7+: 466 (surface detected but not triggered)
Z2.2+: 0 (no surface detected)

Kapton on bare aluminium:
Z0.4-: 537 (triggered)
Z0.45+: 1000 (error)
Z0.8+: 466 (surface detected but not triggered)
Z1.5+: 0

("+" after a Z-value means "this Z-value and bigger")

So what this means is that when probing, the print head goes down (or the bed up in my case), then it senses the approaching surface (represented by a value of 466) but then it goes to 0 again. This leads to the error "probe wasn't triggered during probing move".
So a workaround could be to set the dive height to a very small height but that could be inaccurate since the time between slowing down and triggering is very short.

Hello all!

I recently purchased a roll of polyimide tape from Conrad Electronic (https://www.conrad.de/de/p/polyimid-folie-50-mm-hitzebestaendig-1550728.html) and now I've put it on my aluminium printbed. It was previously covered with blue painters tape which worked great with the IR sensor board. But now with the Kapton Tape it does trigger but only from a very close distance (< 1 mm). This wouldn't be a problem in itself if it could detect the surface from a distance (~20 mm) and slow down until it triggers like it did with blue tape.
Now I'm wondering why it doesn't work like it should since the website about the IR probe and various other people on the internet state that it worked with Kapton Tape.
I also tried putting the Kapton Tape on the blue tape but that also doesn't work.
My guess is that the Kapton scatters the IR light so much that the probe only detects the surface when directly above it. Is that possible? And what could I try to improve it?

Thanks in advance!

Edit: I just noticed that the LED on the IR probe blinks when the sun shines on it and consequently won't trigger on anything. On the website it says that the probe isn't affected by sunlight... so maybe something's wrong with my probe?

Edit2: I just read the website completely and at the bottom it says that direct sunlight interferes with the probe... my bad. But the original problem still persists.

I did design a kinematic mount with magnets (inspired by E3D and this thread: https://forum.duet3d.com/topic/9392/latching-magnetic-tool-changer). Although it's not the intended purpose of this system it does wonders against crashing the head and potentially damaging components.
The only downside is that the cables going to the extruder can exert strain onto it which means that at certain positions of the print head the remaining magnetic force can be very low. This again can lead to the print head detaching and denting (or cracking) the print bed. But a well-designed cable management can definetively solve this...

You might want to look into the Duet3 board. I don't really know much about it but since nobody has replied yet I thought I might give you a hint in the (possibly) right direction. The Duet3 features CAN bus where you can connect up to 24 stepper motors (see https://www.duet3d.com/Duet3Mainboard6HC).
You might also check this interview with Anthony from Duet3D at TCT2019: https://www.youtube.com/watch?v=W6U-u0wBdfQ
As I said, I can't really answer specific questions about this topic but maybe it still helps

Hello all!

Today I printed a small part with a round section (12 mm diameter) where I noticed some rippling at the circumference. Since it is more or less even all around I don't think it is the 'classical' ghosting from vibrations. Instead I guess it's because the jerk value has been set to too low which resulted in the printhead stuttering on its circular path. Decreasing the speed to 60% solved this issue which is another indicator that these are not mechanical vibrations. As far as I'm concerned jerk and acceleration don't scale with the speed multiplier, right?
While thinking about this I asked myself if there's a way to calculate the minimum jerk value for a given print speed and print resolution (aka the length of the individual gcode sections). This could enable the user to set the minimum value possible to reduce ghosting (especially on very heavy printers like mine) without sacrificing print quality due to stuttering in curves.
What are your thoughts on this?

@deckingman The extrusion preview in the slicer around the "D" does show the gap that is also visible in the picture I took. But my problem is the uneven extrusion on the outer "rim" of the part. In the bottom left there are gaps in the zig-zag pattern that aren't there in the top left corner...